Mono: A Developer's Handbook

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.

Comments

No animal on the cover?

[Neil Blender]

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

Re:No animal on the cover?

[davidsyes]

Switch to cells, and add nucleosis... Hmmm. would not be good... mononucleosis...

Re:No animal on the cover?

[lukewarmfusion]

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?

[mopslik]

No animal on the cover?

Since the book deals with Mono, might I suggest a gourami?

Re:No animal on the cover?

[Iron Monkey]

Are you kidding? There are six million 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?

[Thud457]

Here's an appropriate mascot!

Re:No animal on the cover?

[Megaslow]

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?

[FuzzyBad-Mofo]

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.

Re:No animal on the cover?

[Hard_Code]

-2 belabored

Re:No animal on the cover?

[LizardKing]

which language gets the dung beetle?

Cobol

Summary of the next 100 posts

[Swamii]

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

[flashbang]

Yeah, but why not use Java? And who is Miguel?

Re:Summary of the next 100 posts

[lphuberdeau]

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

[aminorex]

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

[pnatural]

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

[iezhy]

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

[javaxman]

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 ?

Re:Summary of the next 100 posts

[Swamii]

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

[ZenHarbinger]

Actually, GTK# also runs under windows.

Re:Summary of the next 100 posts

[Bastian]

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.

Re:Summary of the next 100 posts

[Osty]

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, 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 instance).

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.

Also keep in mind that Microsoft has a 10 year support plan for each new version of the .NET framework. Tha means that 1.0 will be supported for another 7-8 years, 1.1. will be supported for another 9, and 2.0 will be supported for 10 years from release (which should be sometime next year?). That means that even if Microsoft does make breaking changes in a new version of the platform, you can still build applications against older versions that Mono does support. As well, each framework has some amount of backwards- and forwards-compatibility (for instance, it's possible to run 1.1-targeted .NET apps on the 1.0 framework, with a few exceptions). Microsoft generally does a good job of listing backwards and forwards breaking changes between versions of the framework. (Yes, GotDotNet.com is a Microsoft property.)

Re:Summary of the next 100 posts

[Brandybuck]

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.

Re:Summary of the next 100 posts

[Cereal Box]

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 API-compatible with the publicly available API documentation Microsoft has released
3. Microsoft does not care if Mono is ~90% compatible with the .NET standard library because it's full of a bunch of mundane stuff like data structures, I/O routines, and XML/DOM/SAX APIs that are available on just about any platform. To put it another way, 90% of the stuff in the .NET standard library DOESN'T contribute to Microsoft's vendor lock-in, so why would they care if it's implemented on another platform? It's the remaining part of the .NET API that contains anything at all platform-specific (like WinForms), and that stuff can't reasonably be implemented on Linux simply because Linux isn't Windows and lacks the requisite OS-specific software to perform such tasks.

To summarize: Mono isn't going anywhere. There's plenty that Mono can't reasonably implement to allow Microsoft to retain its platform lock-in without any nasty tricks.

Re:Summary of the next 100 posts

[AuMatar]

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 that end, there is absolutely nothing stopping someone from producing .NET bytecode that just so happens to be API-compatible with the publicly available API documentation Microsoft has released

Wrong again. You can patent APIs. I don't know if it has been done by MS, I haven't been wasting my time following all their C# moves. And if it was a submarine patent, we wouldn't know yet anyway.

Microsoft does not care if Mono is ~90% compatible with the .NET standard library

ANything that makes it easier to switch OSes they care about. At the current time it isn't worth it for them to pull the rug out under Mono, nobody important is using it. When someone important enough does, don't be surprised when MS sues.

Re:Summary of the next 100 posts

[ahdeoz]

10 years ago Microsoft was touting Windows 3.11 for Workgroups. Put that in your perspective and puff on it.

Re:Summary of the next 100 posts

[Cereal Box]

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 publicly available, to a standards body, documents describing the bytecode file format and syntax of the language and then suddenly be able to say "no no, you aren't actually allowed to implement any of this."

Wrong again. You can patent APIs. I don't know if it has been done by MS, I haven't been wasting my time following all their C# moves. And if it was a submarine patent, we wouldn't know yet anyway.

Sure you can patent APIs. But there's nothing stopping me from making a functionally and API-equivalent clone of your, let's say, LinkedList class. BTW, you better warn those Wine guys, seeing as how they've been cloning the Win32 API for years.

ANything that makes it easier to switch OSes they care about.

You're missing the point. The ONLY part of the APIs that keeps people locked in to Windows IS NOT the mundane 90%, but the ~10% of stuff that can only be found on Windows.

Re:Summary of the next 100 posts

[AuMatar]

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 there's nothing stopping me from making a functionally and API-equivalent clone of your, let's say, LinkedList class.

If there's a patent, yes there is. Copyright lets me clone with a similar interface I wrote myself, patents block all implementations of the patented functionality.

The ONLY part of the APIs that keeps people locked in to Windows IS NOT the mundane 90%, but the ~10% of stuff that can only be found on Windows.

No, you are. The reason anyone would want to code for Mono is because it would be cross platform. If MS has a submarine patent (and I'd put good ods that they do), they can pull it out from under the Mono developers once they have sufficient userbase. The people running those apps will then have the choice to rewrite in another language, or switch to MS and .Net. Guess what most will choose?

Re:Summary of the next 100 posts

[yo_tuco]

"...the patents they went for covering .NET are so broad they would never hold up in court...."

Do these patents have to hold up in court? I mean, how many Open Source projects (companies or countries for that matter) have the finacial resources to fight Microsoft. IBM could, I guess. But if the Mono project received a cease and desist letter from Microsoft, could they afford the infinite number of appeals Microsoft would litigate?

Re:Summary of the next 100 posts

[gorfie]

I seem to recall 3.11 being a late 1992 innovation, maybe late 1993. At any rate, 3.1 was introduced in early 2002 and 3.11 was the same thing with some advanced networking capabilities.

As for support, the last time I tried to use applications designed for 3.1 they still worked although it's been a while since the applications are so dated. Examples include Eudora 3.0, WS FTP, and a few games. While MS doesn't continue to produce updates/enhancements for 3.x, one can say that the newer versions are at least somewhat backwards compatible (I'm sure there are exceptions).

Just my thoughts... on a related note, I was in a .NET class today and the instructor was touting XML configuration files (i.e. registry updates via applications are old). Sounds almost like the .ini files from Win 3.x. :)

Re:Summary of the next 100 posts

[omicronish]

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 probably), and it's safe from a coding standpoint for Mono to make an equivalent implementation without worrying about breaking changes.

Microsoft can extend and modify .NET with newer versions, such as the currently-beta 2.0, but .NET versions can and are designed to be installed side-by-side, so applications that use 1.0 or 1.1 still need the respective version of the framework installed. If you want to check this for yourself, take a look at the C:\Windows\Microsoft.NET\Framework directory. I currently have the subdirectories v1.0.3705, v1.1.4322, and v2.0.40607

Re:Summary of the next 100 posts

[AstroDrabb]

Stop the FUD. Mono has this covered here. A small part of the FAQ

Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms

All MS could make Mono take out would be ASP.NET, ADO.NET and Windows.Forms if the Mono project could not find prior art. That still leaves the majority of Mono including the entire OSS stack such as GTK#, QT#, wx.NET (sweet x-platform on Mono), mono-cairo, Database providers, and tons of other technology that make for a nice Linux and x-platform development environment. So to correct your FUD, MS cannot "rip" Mono out from under anyone. The worse case senario is the removal of ASP.NET, ADO.NET and Windows.Forms. Though that would usually be pretty easy to work around and keep the API's the same. There is really no way for MS to take away Mono.

Re:Summary of the next 100 posts

[Bastian]

Eh, it's what OS X uses for configurations.

Personally, I like it. Throwing everything together in a huge registry is a can of worms just asking for trouble.

Re:Summary of the next 100 posts

[WaterBreath]

Why use C#?

I use C# rather than Java for Windows development (I haven't done any Linux development... yet) because for 2 big reasons, and 1 little reason:

1. The existing .NET libraries, I feel, are simpler and easier to extend than Java's libraries.
   
2. .NET libraries/components are much nicer than DLLs and COM for most applications.
   
3. The standard Java look-and-feel is not even as aesthetically pleasing as the standard Windows look-and-feel. (Though they are equally hard to replace.)

And that's just what I can think of off the top of my head on the spot.

Re:Summary of the next 100 posts

[kundor]

How do you stop a loose worldwide framework of developers from coding?

Objective-C

[remahl]

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

[Swamii]

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, or this paper from PyCon 2004.

Re:Objective-C

[jeif1k]

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

[imroy]

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

[Swamii]

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

[ari_j]

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.

Re:Objective-C

[myrdred]

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

Re:Objective-C

[LizardKing]

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.

Re:Objective-C

[yason]

Awww, I really hope IronPython evolves into something usable. (I miss Jython already, as it seems to be mostly dead.) Or that a good Common Lisp implementation turns into GNG/CLisp# (GNG == GNU or Not GNU).

I'm not particularly interested in C#, as far as I know there's nothing new in that language.

Then again, I'm somehow thrilled by the CLR and the libraries. I feel that'll be a major step forward in terms of a programming environment. I sometimes see it as the i386 of the future: a common machine to write programs for but just way higher level than machine language. It was about time: we've been compiling C and other languages to machine code for decades. It's about a time to upgrade to "future hardware" that'll handle all basics from memory management and GC to run-time optimization.

There will be Gnome# libraries and Windows Forms# libraries, as we now have Gnome and Windows. However, they'd share much more in common than their i386 counterparts. I believe the CLR runtime environment will eventually be what JRE never achieved. Java failed because of the JRE was tied to Java, and often vice versa. It's like bundling a processor family to a specific assembly syntax: "sure, but what'd be the point?".

Please note that I don't consider posting this touting MS technologies. I've seen quite a many things: I very rarely get excited about "new" software or technology. In fact, even CLR isn't new in technological sense: the new thing is that it has a huge probability of rolling over to everywhere. It's not only pushed out by Microsoft but also adopted by FOSS folks (Mono, Gnome#, Gtk#, QT#..)

I've been dreaming of a Python bytecode/Lisp bytecode desktop where all applications would be written for a virtual machine, and possibly JITted to machine code if ever needed. With the advent of CLR and Python#/CLisp#, and access to one's favorite widget sets, that'd be closer to reality than ever on a general-purpose PC. (Since there used to be these dedicated Lisp machines back in time..)

Re:Objective-C

[namekuseijin]

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

Interesting how things change when money is involved, huh? By Java's open nature, it was unlikely anyone would ever give him a job for Jython alone, but what about beginning a project to port Python for .Net? It is very well known that M$ treats developers real good, heck why not? Well, good for him! At least he can come out with as good an implementation as .Net possibly can.

Anyway, i agree with parent about ObjC. The author doesn't know what he's talking about, comparing a statically typed, tiresomely declarative language like C# to the likes of Python or Ruby. Sure ObjC feels a lot more close...

Mono

[NoInfo]

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

Re:Mono

[xtort17]

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

[mreed911]

Shhhh!!! Quiet, else Symantec might patch NAV to detect MONO as a virus!!!

Re:Mono

[jav1231]

Yeah, Miguel kissed up to M$ and caught .MONO!

Re:Mono

[aero6dof]

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

Re:Mono

[vgaphil]

I thought I had Mono for an entire year, turns out I was just really bored...

Re:Mono

[Slime-dogg]

Well, if you hadn't been sucking face...

Mono

[Anonymous Coward]

I had Mono in 7th grade, it sucked.

This is a boffo follow-up to hugely successful...

[Anonymous Coward]

Mono: An Incubator's Handbook

Re:What about java?

[Swamii]

Not quite. A better comparison,

Mono is Novell's implementation of this standard.

On the other hand, .NET is Microsoft's implementation of this standard.

Same standard, 2 different implementations of the standard.

What, no VB?

[Nom du Keyboard]

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?

[Naikrovek]

vb.net support is planned. check it

Re:What, no VB?

[bendermannen]

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?

[fitten]

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?

[Anonymous Coward]

You should really read up on what youre talking about before posting

He develops in VB...what else did you expect? They just point and click and type in a database source, assume all is well with the world and think they are Top Coders. I'm not trying to flame here, but my experience with VB developers has been that VB is all they know, and no matter how proficient they are with it, they dont ever truly get a grasp on how a computer, compiler, or any of the related, really work. Also (keep in mind this is my personal experience with VB developers), VB Developers often only know one language (VB of course) and still call themselves programmers. I'm sorry but no real programmer only knows one language, sure you may only typically use one language, but anyone who takes coding seriously knows *at least* one other language and perhaps a few scripting languages too. What I'm getting at is that just to be a programmer and be good at programming, you need a good understanding of many things, VB coders typically don't know much beyond point and click and occasional typing of an "if" statement. I've met many VB coders who had no idea that a gui was generated by code, honest to God, they thought it just kind of magically appeared after being dragged and dropped and you made your exe, probably because they never saw the code for the gui. One guy saw me coding up some C++ in vim and was not only confused by the syntax, but was also amazed to see a window appear when I ran my program, he asked me how I did that without designing one, he thought I was using an activex control or something to do it for me (BTW, I was on linux, and apparently alot of things in VB are done with activex). I almost went insane. Then I explained how you can do all that without a little form designer, simply by coding it. He was shocked and I still don't think he fully understood.
Regards,
Steve

Re:What, no VB?

[kundor]

Are you confusing the IDE with the language?

Mono vs .NET Framework

[Nick of NSTime]

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

[trendzetter]

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

[jblake]

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

[steve_deobald]

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

[Oxy the moron]

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

[jeif1k]

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

[BigGerman]

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?

Re:Mono vs .NET Framework

[XMunkki]

It might be intresting to see, as monos' Windows.Forms support advances, how #develop would succeed as an IDE. It's basically a GPL'd version of the VS.NET IDE.

Sweet Spot?

[Freedom Bug]

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?

[tcopeland]

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

[j1bb3rj4bb3r]

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?

[Swamii]

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

Re:Sweet Spot?

[jeif1k]

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?

[Jonathan]

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?

Re:Sweet Spot?

[bushidocoder]

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 framework and toss in the added benefit of every other .NET/Mono application being able to take advantage of your Python libraries.

btw - Being able to run stored procedures written in Python on the SQL Server 2005 beta is pretty cool. I still can't find a good reason to write a stored procedure in any language other than T-SQL, but its still kind of fun.

Re:Sweet Spot?

[bushidocoder]

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 world. .NET also doesn't really appear in a non-x86 architecture and probably wouldn't perform as well - Not surprisingly .NET IL looks to be pretty biased to the x86 architecture. But for every runtime optimization the Java world can build, the .NET CLR team can match it and build in another option the Java camp can't without a pretty drastic change to some of the core internals.

(note that when I talk about .NET, I'm referring to the Microsoft .NET CLR - the Mono CLR is still pretty slow to my experience, but getting better by the day

Re:Sweet Spot?

[j1bb3rj4bb3r]

0x2BAD4ADA

Re:Sweet Spot?

[caseih]

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++. Python and Perl also have bindings that are very comfortable within their own object framework.

Re:Sweet Spot?

[criscooil]

What kind of code falls between the 2?

You must be kidding! Java (and C#, whatever) is the perfect compromise: all the blinding speed of scripting languages combined with the quick-n-easy development process of trad. compiled languages. What more do you want?

Re:Sweet Spot?

[Axe]

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.

Re:Sweet Spot?

[Axe]

The performance of Sun's Java implementation is excellent

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

Re:Sweet Spot?

[Marcus Green]

Can you point to significant numbers of job adverts that are asking for a combination of Python with QT? When I just did a search on my favorite job website I got 32 records matching the term Python and 2,890 mathing the term Java.

Re:Sweet Spot?

[Peaker]

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, I use Pyrex 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?

[Anonymous Coward]

It's a myth that C/C++ is particularly fast or efficient for those applications

No, its not a myth. Language implementation benchmarks, like http://shootout.alioth.debian.org/ prove this. Not only is C/C++ the fastest option but also the most memory friendly one. C++ in particular offers nice abstractions that those "modern" VM languages still lack or provide only half-hearted (eg. templates). Anyone who claims that Java or C# is suitable for embedded environments does not know what she is talking about.

Re:Sweet Spot?

[jeif1k]

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 there are still limitations when it comes to inheritance, memory management, and when mixing Gtk+, Python, and some other OO language.

Re:Sweet Spot?

[tyrantnine]

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.

I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived! Please back up this wonderfully baseless statement with some substance.

One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it". Do a quick look around at talk of the impending C++0x standard, and you'll see this mantra is alive and well to this very day... and the lack of some "language features", like forced garbage collection, don't exist it for this very reason.

To point to QT and GTK and somehow equate these very fine libs/toolkits was a "sad example" of how C/C++ forces people to "re-design things badly" reflects some serious ignorance. It only took one reply to another poster to totally contradict yourself and say GTK is in fact, a well designed toolkit. The fact you qualified it with "as well as could be done in C" shows you're a language war fanboy, and most fanboys are beginners who don't know any better.

Java/C# and even C++ really aren't wildly different languages. Fanatics claiming 500x speedups in their development time are immediately red flagged to me as ignorant.

Re:Sweet Spot?

[kma]

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.

Nice paraphrasing of conventional wisdom, and you're 100% right for anything that runs at user-level. The OP said "operating system kernel," though, and like it or not, kernels run on bare metal. Anything that low-level requires that you write in a language that closely approximates the naked hardware. Unless your CPU has a "new" instruction, that means writing your own memory allocation facilities, typing, etc., no matter what.

So, while it's a "myth" that C is "especially efficient," anybody writing an actual OS will be writing a heck of a lot of C and assembler. Even if you want to write your OS in C# or Haskell or whatever, you'll only get to do so after you write a runtime for your language in something more low-level.

Re:Sweet Spot?

[Junks Jerzey]

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?

[Peter La Casse]

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, I use Pyrex for the inner loop, typically a single function or class.

Wow, what an awesome pair of projects. With a quick apt-get and two lines of additional code, Psyco cut my program's execution time in half.

Re:Sweet Spot?

[cakoose]

The faster your language, the less frequently you'll have to resort to C code. Statically typed languages are faster.

Re:Sweet Spot?

[jeif1k]

In my experience, the latter far outweighs the former (as long as raw performance isn't the issue).

The operative word being "my"; static type checking becomes important when developing large systems over a long time and/or with many developers.

Also, static type checking, interactive development/testing, and zero compilation times are not mutually exclusive.

Re:Sweet Spot?

[jeif1k]

The OP said "operating system kernel," though, and like it or not, kernels run on bare metal.

The problems don't go away just because it's in the kernel: modern kernels still need to clean up their resources, get software components to talk to each other nicely, and not crash when there is a bug somewhere.

Even if you want to write your OS in C# or Haskell or whatever, you'll only get to do so after you write a runtime for your language in something more low-level.

Support for garbage collection, dynamic typing, and runtime safety in a language do not preclude the use of that language for implementing low-level features. Furthermore, such languages can demonstrably be used to implement their own runtimes and kernels; except for a few scattered assembly language instructions for things like CPU mode switching and register initialization, no code needs to be written in assembly language.

Haskell lacks some necessary facilities, but Modula 3, Ada, C#, and some varieties of Lisp, Java, and Smalltalk have them and several of them have been used for those purposes.

Re:Sweet Spot?

[lars_stefan_axelsson]

I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived! Please back up this wonderfully baseless statement with some substance.

One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it". Do a quick look around at talk of the impending C++0x standard, and you'll see this mantra is alive and well to this very day... and the lack of some "language features", like forced garbage collection, don't exist it for this very reason.

Being old enough to have been around the introduction of 'C' to the masses (i.e. the PC) and the abandonment of assembler it's amusing to see the same arguments recycled all over. Only this time it's 'C' that's leet:small, fast, not bloated etc, instead of assembler. And higher level languages such as 'Python' that are 'slow/bloated/have a lot of stuff you have to pay for even if you don't use it' instead of 'C'.

Last time around the debate was settled squarely in favour of 'C', that while it was killed dead in micro benchmarks compared to assembler, when it came to projects of any size, the added ease of development actually meant that programmers weren't bogged down in detail and could actually concentrate on doing the right thing (instead of merely doing things right). With huge savings in development time and even efficiency of the developed application. Since you hadn't spent all your time getting it to work, and you could express yourself using more abstractions you could actually tune and throw away code you had written replacing it with something that implemented a better algorithm.

A few companies did stick to their guns and continued with assembly for everything ("because it was faster, God damn it!"), and perished as a result. The original company behind WordPerfect comes to mind. They folded had to sell WP (which had to be rewritten in something higher level, and that rewrite made it slip behind its competitors).

Within Ericsson we've seen that particular light and developped our own system (Erlang) which enables us to produce world class systems faster than the competition. Systems which also have better performance than our competitors. (See AXD301 and our GSN line). This despite Erlang being killed by 'C/C++' in micro benchmarks. System level it rules the roost. (That's not to say we don't use 'C', we do, just like assembler wasn't abolished by 'C'. But we use it where it belongs for device drivers and the like, not code that actually does anything. Our experiences with C++ gives us pause though, so no C++ if it can be helped.) Lots of nice papers on the Erlang site above. And note that when it comes to performance claims these are verifiable claims.

So if you're a competitor of Ericsson, please continue using C/C++, our continued success depends on it. If you're not, then you better prepare to wake up and smell the roses. History looks set to repeat itself and you don't want to be stubbornly stuck in your old ways and go the way of the WP team when the wind shifts.

Re:Sweet Spot?

[tcopeland]

> libcurl might be in /usr/lib, or
> /opt/lib, or /home/foo/lib)

Sure! Ruby can also load a library off the PATH, too.

> This is what we mean by "scripting
> languages don't scale".

Hm. How is loading a shared object library involved in "scaling"?

Re:Sweet Spot?

[Junks Jerzey]

The operative word being "my"; static type checking becomes important when developing large systems over a long time and/or with many developers.

And "my" includes keeping an eye on large projects written using dynamically typed languages. Consider Ericsson's massive systems written in Erlang, for example. And there are plenty of good examples of large systems written in Python and Lisp, though note that "large" isn't in the same category as Ericsson's work (where "large" means 1,000,000+ lines of code).

Re:Sweet Spot?

[jeif1k]

People have written systems consisting of millions of lines of assembly language, too. Just because people do something doesn't mean it's a good idea.

Re:Sweet Spot?

[jeif1k]

I'm sorry, it's a myth? Apparently many millions of people, many far better programmers than you, have completely been deceived!

You are absolutely right, they have.

One of the core ideas behind the design of C++ is "if you don't use it, you don't pay for it".

If you live in a hovel, you also don't pay for things you don't use.

Java/C# and even C++ really aren't wildly different languages.

They are quite similar in the sense that they all use a lot of braces. That's pretty much where the similarity ends, however.

shows you're a language war fanboy, and most fanboys are beginners who don't know any better.

Like your other ideas, you are wrong there as well. I have more than 20 years and several hundred KLOC of C programming under my belt (Saber C and Purify made it more bearable). Unlike you, however, I know better than to think that just because it can be done and people pay for it, it must be a good idea.

Furthermore, if anything, I'm an "anti-fanboy": I'm saying that C and C++ are almost uniquely bad in their disregard for type safety and runtime safety. Java and C# just happen to be the most popular alternatives right now.

Re:Sweet Spot?

[Just Some Guy]

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

I know I'm coming into the conversation rather late, but anyway...

I interviewed for a position that partially included maintaining and upgrading the locally-written plugins to some CAD package or another. Basically, the drafters would use the program to design large steel structures, and then they'd use a hodge-podge of Fortran to run stress analysis reports on each item and joint.

I had always assumed that CAD was sort of like a 3D vector drawing program, but I was apparently grossly mistaken.

Re:Sweet Spot?

[tyrantnine]

You are absolutely right, they have Your arrogance is amusing

They are quite similar in the sense that they all use a lot of braces. That's pretty much where the similarity ends, however. Are you joking? The syntax and semantics are in many cases nearly identical. Most keywords are shared, and others are basically simple synonyms, and the same goes for syntax differences. There are little details here and there, but things are very similar right up until memory management and pointers, where C++ obviously breaks off

Like your other ideas, you are wrong there as well. I have more than 20 years and several hundred KLOC of C programming under my belt (Saber C and Purify made it more bearable). Unlike you, however, I know better than to think that just because it can be done and people pay for it, it must be a good idea. I stated one of the design decisions behind C++ and that it will never therefore have a GC - and to say that a language without a GC is somehow horribly broken is just pure naivety. Neither did I disparge one language over another, as you seem to imply I did.

Perhaps you are anti-fanboy after all. Maybe you're one of those who bloviates as if they know something while making it clearly obvious they don't. To you, and your obvious genius, everything is flawed, all stifling your abilities. Your suggestion about System-level programming and language choice is just flat stupid, and your comments regarding QT/GTK were at best ignorant. If you really have 20 years of coding experience, I suggest you consider an early retirment.

Re:Sweet Spot?

[jeif1k]

I stated one of the design decisions behind C++ and that it will never therefore have a GC

"You don't pay for what you don't use" makes a great slogan. But products often promise something and fail to deliver. In particular, in C/C++, you pay dearly for the use of manual storage management, both in terms of performance and in terms of safety.

Are you joking? The syntax and semantics are in many cases nearly identical.

Java and Java-without-new would be nearly identical languages, yet they would be very different in practice. To discuss similarity between languages, one has to talk about how the languages work for software development.

To you, and your obvious genius, everything is flawed, all stifling your abilities.

As I was saying, there are plenty of decent languages and platforms. Just pick anything other than C/C++ and chances are you will be much better off.

If you really have 20 years of coding experience, I suggest you consider an early retirment.

Why should I? It has taken a while, but the industry is coming around to my point of view: Java and C# are hugely popular for new projects, while C and C++ are more and more relegated to legacy code. You are the anachronism, the software equivalent of a member of the "flat earth society". Sounds to me like it's time for you to retire.

Re:Sweet Spot?

[kundor]

I think you're thinking of WordStar, which died due to their persistence in using assembler -- and never came back.

Re:Sweet Spot?

[lars_stefan_axelsson]

Well not quite, I was really thinking of WordPerfect but it seems I got the timeline slightly wrong. They survived the rewrite to 'C' and only later sold to Novell. They were steadfast with their assembly nonsense for everything before that though, so maybe the damage was already done.

WordStar may have been a parallel though. Even though my vote in that case goes to the arcane command set :-)

Re:Sweet Spot?

[tyrantnine]

"You don't pay for what you don't use" makes a great slogan. But products often promise something and fail to deliver. In particular, in C/C++, you pay dearly for the use of manual storage management, both in terms of performance and in terms of safety.

Another broad claim, and certainly in the case of performance, struggling to grip with a wide variety of blindlingly obvious fact.

"Java and Java-without-new would be nearly identical languages, yet they would be very different in practice. To discuss similarity between languages, one has to talk about how the languages work for software development."

Actually, no. When time gives us perspective, I am quite sure any genealogy of languages will be grouping Java 5, C++ '98 and C# very closely on the same branch of the tree. Good grief - just look whats been added to in Java in it's latest incantation - enums, "generics", and wonder of wonders, printf!

A real example of something thats quite different to use in practice might be a functional language like say, Haskell. Java C++ transistion is rather easy to describe to a programmer of either language preciesly because the language structure and syntax are so incredibly similar. Java Haskell is not at all, though both feature a GC.

As I was saying, there are plenty of decent languages and platforms. Just pick anything other than C/C++ and chances are you will be much better off.

I guess I was right in the first place - you are just a language war flameboy.

Why should I? It has taken a while, but the industry is coming around to my point of view: Java and C# are hugely popular for new projects, while C and C++ are more and more relegated to legacy code. You are the anachronism, the software equivalent of a member of the "flat earth society". Sounds to me like it's time for you to retire

Once again, I never promoted anything. I know you're desperate to attack something since you're wildly trying to win a hopeless point, so I'll forgive you.

Rabid love or hate one way or the other is irrational and usually the sign of a novice. Sorry! Most people want to believe whatever they know best, or prefer, is the best. _Most_ programmers with any measurable breadth can sit back and shake their head. Sorry!

Re:Sweet Spot?

[jeif1k]

_Most_ programmers with any measurable breadth can sit back and shake their head. Sorry!

I completely agree that most programmers still agree with your point of view. That's why so much software is still full of security holes, crashes so frequently, requires hundreds of megabytes of memory, and misses so many deadlines.

struggling to grip with a wide variety of blindlingly obvious fact.

Yes, the facts are blindingly obvious.

Re:Sweet Spot?

[tyrantnine]

I've never argued in this context that C/C++ doesn't offer you more ways to blow your foot off as far as insecure code goes than the other two languages we've targeted. However its rather odd that you responded to my statement about performance with a "retort" about security.

I'm sorry, a rational viewpoint rather than rabid fandom (or hatred) of widely similar languages doesn't quite equate with your implication. If you're truly naive enough to believe switching to Java or C# (if, it were possible in all cases) will magically transform all the code in the world to secure, bug free, resource light, faery paradise, you are truly lost. Frankly I have almost no doubt you've greatly exaggerated your experience as a programmer.

Anyway, I now remember why I so rarely choose to get involved in extended comment discussions on slashdot. You've got a small mind and a big mouth, never a good combination.

Re:Sweet Spot?

[Axe]

No. I design quite different stuff.

mono

[pizza_milkshake]

one time i thought i had mono for an entire year; but it turned out i was just really bored.

It's not the language that counts...

[Dante Shamest]

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

Re:It's not the language that counts...

[imbaczek]

They should add a socket class first.

Re:It's not the language that counts...

[Axe]

Yep. And threads. And JDBC equivalent.

And frigging HASHMAPS.

And regular expressions.

And..

People who claim C++ does everything have not done commercial development. And the hell of thrid party libraries (RogueWave anyone?)

I thought...

[Rorschach1]

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

Before anyone starts trolling...

[adolfojp]

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

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

Re:Before anyone starts trolling...

[david.gilbert]

More to the point, Miguel is convincing many other people he is right, even when he is not, and is thus detracting from the quality of my OS/Environment. It's not that he's wasting his time, it's that he's wasting my time.

Ever wonder how Miguel got into this position of being more convincing than you are?

Re:Before anyone starts trolling...

[Axe]

Ever wonder how Miguel got into this position of being more convincing than you are?

Shit happens. (That is actually a perfectly serious answer).

Re:Before anyone starts trolling...

[BollocksToThis]

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.

Ok, fine.

Why Mono and not Java? Mono is 100% open source, and it's not Java!

Re:What about java?

[tonyray]

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.

Cobol

[TheIronDuke]

I want to use Object Oriented COBOL.

Re:Cobol

[Unoti]

You can. Fujitsu implemented a COBOL.NET. It's an abmonination.

Re:Cobol

[steve_deobald]

Cobol and .NET, together at last. - Your prayers have been answered! ;)

Re:Cobol

[The Wookie]

.. and in the tradition of C++, this language would be called "ADD ONE TO COBOL"

For the uninitiated

[mreed911]

If you have questions about Mono, read the project launch statement or visit the list of Frequently Asked Questions.

There's an RSS feed for the newest news, updates, etc. on Mono, too.

Developing Mono.

[holzp]

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

Re:Developing Mono.

[shirai]

Is this related to the ominous statement in their FAQ:

Question 7: What does the name "Mono" mean?

Mono is the word for 'monkey' in Spanish. We like monkeys.

Why bother?

[laird]

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?

Re:Why bother?

[Sir Homer]

I'm with you bro, I looked at C# for a few hours and never went back. There is no point to switch languages if the one you are currently using is doing fine for you. All .NET and C# feel to me are buzzwords/marketing promoted by MS, not technology. I've encountered real geeks who didn't know that Centrino is actually a marketing buzzword.

Re:Why bother?

[cakoose]

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?

C# is better than Java in almost every way:

• C# has function pointers (delegates) and closures (this is the biggest draw for me).
• The CLR's generics implementation is more efficient. Java's ArrayList<Integer> is painfully inefficient.
• The CLR's generics implementation is more complete because it retains runtime information about type parameters. Java's generics has some limitations ons what a type parameter can be.
• C# has better virtual method annotation syntax; non-virtual by default, explicit override, explicit shadowing.
• C# has a simple way of making sure you dispose resources.
• "unsafe" mode. Now you can stay in C# for many tasks that you used to have to write C code for. Unsafe code is platform independent.
• This is more of a CLR thing but Java really needs an AppDomain-like isolation facility. They're working on it, but it's a little late now.

You may hear about these "features" from pro-CLR people:

• Value types. These are bad. They just fragment the type system. A good compiler can figure out how to speed things up requiring that you mess up the type system.
• Language agnostic. This is not true. How are you going to call overloaded functions from C? What about dynamic dispatch on parameters? The API is very C++/Java-centric and will have to stay that way. The CLR does have slightly better interoperability, though.

The only advantages the Java language has (that I can think of) are:

• Flexible variant typing.
• More powerful enums.

It's true that C# is mostly copied from Java. They didn't add any novel ideas. They just improved it incrementally (and screwed up a little too). But after everything is accounted for, it's clearly a better language. You can talk about "maturity" and "industry support" all you want, but some people are just happy to be using a superior language.

BTW, both "maturity" and "industry support" wont be problems for C#. It's not hard to design a mature language and set of class libraries when you have a working example to learn from. Also, Microsoft has mature designers working on the CLR and that counts for something too. As for "industry support", you have got to be joking. When they make the CLR come pre-installed on Longhorn, it will instantly become an industry standard. Even now it's available directly through Windows Update. The whole XAML/Avalon thing is not even ready yet but Amazon.com has already used it to build a prototype. It's depresing, but true: anything that comes out of Microsoft will have a completely unfair advantage over any competing products. Macromedia is next.

Re:Why bother?

[laird]

"C# is better than Java in almost every way:"

About half of C#'s "advantages" are capabilities that the designers of Java considered and rejected as being a bad idea (by making the runtime less stable and secure, unnecessarily complex, etc. -- I knew Guy Steele at the time, and he certainly was aware of operator overloading, generics, etc., and made the (smart, IMO) decision that it was more important to make the language,compiler and JVM (and security model) simpler, smaller and more predictable). You might as well argue that multiple inheritence is "better" than single inheritence; it's certainly useful at times, but it makes it much harder to read code and know what it does, which in the long run is more important than solving some fairly obscure modeling scenarios. Certainly the way that C# deals with native code is nicer than Java, and the Java GUI frameworks aren't great (though there are multiple, competing GUI frameworks to choose from, and SWT is great). But C#'s advantages are, as you point out, not a matter of any novel ideas, just making some incremental improvements and different mistakes, so overall (IMO) it's not clear to me that it's really "better" than Java, just very similar with some different, debatable design decisions.

"As for "industry support", you have got to be joking."

By industry support, I mean that there are many more Java programmers than C# programmers, many more companies and open source projects providing Java resources (libraries, app servers, etc.) than C#, etc. Yes, MS is big, but are they bigger than IBM, Sun, BEA, etc., not to mention the entire Java development community? Yes, MS can through sheer muscle get their VM distributed onto PC's, so there's no doubt that eventually they'll be able to drive a chunk of the world to use C# (i.e. it'll be easy to get some people who use only MS tools to use MS's new tool), but Sun's got JVM's made nearly universal on cell phones, preinstalled on millions of PC's, etc., ... so while MS does have powerful marketing muscle, pretty much everyone else in big the tech space committed to Java years ago, and has been investing $billions in making sure that they're ahead of MS.

And we can look at SourceForge as a rough measure of Developer support. Of the roughly 90K projects, 12,784 are in Java, and 1,824 are in C#. So after a few years of a massive PR push, C# is at 14% of Java's adoption. Not to be sneezed at, but that puts it as a contender to Delphi (1,557) and JavaScript (1,932), which are relatively obscure as application languages. At least it's more popular than TCL (816) or Prolog (89).

Or let's look at the number of app servers available. How many companies provide J2EE implementations are available? See http://www.theserverside.com/reviews/matrix.tss -- they list 30+ companies. How many companies provide .Net app servers? I can't find a list, but I only know of one. :-)

So I guess what you're arguing is that with MS behind it, C# is going to get lots of developer support, and will mature, eventually. That's probably true, since MS is unlikely to cancel C# (more embarassing to kill C# than Bob...). But it hardly shows that C# has more industry support than Java.

"When they make the CLR come pre-installed on Longhorn, it will instantly become an industry standard"

If the CLR's penetration is driven by Longhorn, that means that it won't be something developers can assume until when, 2009? Look at XP -- completely anemic takeup rates, essentially zero consumer upgrades, so it's only being deployed as new system purchases, which means something like a five year replacement rate. In the corporate world, Windows 2000 is the standard platform -- upgrading to XP is messy enough to deal with that most large companies are still forcing vendors to ship new PC's with Win2000 to keep XP out of their environment to maintain a standard, supported platform. So

Re:Why bother?

[cakoose]

About half of C#'s "advantages" are capabilities that the designers of Java considered and rejected as being a bad idea (by making the runtime less stable and secure, unnecessarily complex, etc. -- I knew Guy Steele at the time, and he certainly was aware of operator overloading, generics, etc., and made the (smart, IMO) decision that it was more important to make the language,compiler and JVM (and security model) simpler, smaller and more predictable).

Sure, Guy Steele is smart, but that doesn't mean he he never makes mistakes. At the time, the Java designers tried to eliminate unnecessary complexity, but it's hard to decide what "unnecessary" means without seeing the language in action. He now seems to think otherwise about generics and operator overloading (if, in fact, he originally thought they did not belong in Java), probably after seeing the collections and BigInteger in action.

You haven't made any specific arguments about how the features add unnecessary complexity and make the runtime less secure, but here's what people usually say:

• "Operator overloading can be abused." Yes, it can be. But it doesn't have to be. There are ways to write obfuscated Java programs with the 1.0 language spec. You cannot eliminate obfuscated code. You just have to set a good example with the standard class libraries and use operator overloading only when it makes sense.
• "C++ templates are really complicated, so generics must be really complicated." Generics are much simpler than C++ templates. They don't bloat the code, they use explicit constraints to make error messages more sensible, and you don't have to ship template classes around in source form. I don't know why you mentioned generics, though, since Java 1.5 has them.
• "Unsafe code compromises the safety of the system." Yes it does, but that's something the developer is aware of. The safe subset of the CLR instructions is just as complete as the entire JVM instruction set. Unsafe code is meant to be used as an alternative to some of the cases where you were forced to use JNI. Unsafe code is portable in compiled form, unlike an application that uses JNI.

What C# design mistakes make it worse than Java? Though I think value types were a mistake, Java doesn't really have a better way of handling them right now. I also mentioned that Java has better enums and variant typing. That's all I can think of (please respond if you can think of any more). Those advantages don't outweigh C#'s: function pointers, closures, generator functions, fast generics, isolatable runtime contexts, etc. C#'s improvements over Java probably won't make it worth your time to port your application, but there's no question that it is, overall, a better language.

Industry Support

Yes, Java has more industry support and more industry support is definitely better. However, there's a threshold after which you can safely use a language without worrying about tool support or the variety of available libraries. It's not a well-defined line, but C# is definitely going to cross it very soon. For many developers, the current level of support is probably good enough.

How does Java have better desktop platform penetration? It doesn't come with Windows either. Some OEMs might pre-install the JRE, but those OEMs are probably just as willing to pre-install the .Net runtime. While Longhorn wont be out for a while, it will be preinstalled by all the major desktop vendors when it does. It's not likely that Solaris (or any other OS that comes with Java pre-installed) will have a significant share of the market. It could happen, but it's a sensible decision to bet on Microsoft winning out again.

Companies that want uniform environments are willing to pre-install MS Office and Adobe Acrobat on all employee desktops. Why wouldn't they be willing to make the free .Net runtime part of the standard installation?

Who needs a book?

[SensitiveMale]

I developed mono back in the 7th grade.

Argh!

[be-fan]

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!

[ari_j]

You didn't cite any examples of weak dynamic typing, like Tcl. Don't forget Tcl!

Re:Argh!

[lkaos]

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

Re:Argh!

[ajs]

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.

Re:Argh!

[BarryNorton]

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' typing at compile time, despite the inability to actually verify safety).

Re:Argh!

[mikec]

Why? Because if you violate type rules in C/C++, arbitrary nasty behavior can occur. For example, your program may complete "successfully" with no hint that anything went wrong, but with an entirely wrong answer. If you violate type rules in Java, you get (at worst) a well-defined runtime error.

And as of the latest Java, there are strongly typed collections:

Map<String,Integer> map =
new HashMap<String, Integer>();
map.put("Foo", 3);
int x = map.get("Foo");

so I guess we can finally retire that argument.

Re:Argh!

[be-fan]

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!

[be-fan]

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

Re:Argh!

[ari_j]

If you hate Tk and want to forget Tcl, I recommend Ruby/Tk. The tutorial web page is almost as ugly as the output!

Re:Argh!

[be-fan]

You're confusing strongly typed with statically typed. Strong vs weak typing refers to safety. In strongly typed languages, type safety is enforced, with no loopholes. Both ML and Java meet this criterea.

Re:Argh!

[lkaos]

Um, dude, static typing means that a variables type is defined at compile time. Polymorphism is a dynamic typing mechanism.

All containers in Java are polymorphic. Since we still like to say Java's statically typed, we say it's weakly typed.

For the most part, people don't have polymorphic containers. It's a practice not generally recommended in the absentence of a strong pointer wrapper.

RTTI would be that information know at runtime. It's at least limited in C++, but every non-primative shares the same base class in Java so there's quite a bit of instanceof's going on as people are forced implement Object interfaces for things like equals or compareTo.

If you wrote all of your Java code to take Objects are your parameters, how would this be different from a dynamically typed language?

Re:Argh!

[be-fan]

I call Java statically typed only because what people usually consider it to be. In general, it's statically typed with polymorphism as an extension. It's not really fair to call it a dynamically typed language, even though it's not as statically typed as something like ML.

It is, however, strongly typed not weakly typed.

Re:Argh!

[lkaos]

I don't think the technical reason that people consider C/C++ weakly typed that you can get undefined behavior with casts but rather that C is pretty nasty about implicit casting to void* in that it does it all the time.

You get weird things like void* to implicit int casts too. I believe that's why C gets this distiniction. However, this was pretty much eliminated in C++. I don't think it's fair to say C++ is weakly typed..

And you can do the same thing in Java too btw. It's a well known Java weirdism.

You can have a single array of type Shape with base classes Square and Rectangle. If you initialize the Shape array with a Rectangle away, you can then assign the Shape array new Square elements. No exceptions, you won't get an error until you actually try to use the element (not when you cast).

Re:Argh!

[lkaos]

If you violate type rules in Java, you get (at worst) a well-defined runtime error.

That doesn't sound very static to me..

And btw, take a look under the covers at the new collections. They're implemented internally by new'ing Object[]s b/c of the weirdness of Java generics.

Also they provide object accessor methods.

You've also demonstrated one of Java's weak-typed new features--autoboxing. int's get converted to Integers automagically now. Again, not very static nor very strong.

Re:Argh!

[be-fan]

It's an all or nothing thing. You're strongly typed if you catch all type errors. Java (barring bugs in the VMs), does. If a language don't catch all type errors at compile-time or runtime, then it's weakly typed.

Re:Argh!

[mburns]

Tcl has shimmering type conversions with two different representations of the value (virtually) available at all times. Type conversion is not the same thing as loose typing. A type accident in Tcl would be a bug in the language implementation, and not something for which the blame can only be shifted onto the programmer as in C.

Tcl adds shimmering type conversion to competency in all of the important Lisp idioms and easy connection to Unix functionality. The other scripting languages do not compare to Tcl in their Lisp functionality, and thus they do not rival Tcl in my preferences.

Re:Argh!

[Haeleth]

In strongly typed languages, type safety is enforced, with no loopholes. Both ML and Java meet this criterea.

Not necessarily. For example, OCaml (one of the most popular dialects of ML) is universally considered strongly typed, but it still has loopholes.

$ cat oops.ml
(Obj.magic 0) ()

$ ocamlopt oops.ml -o oops
$ ./oops
Segmentation fault (core dumped)

Oops!

Does that mean OCaml isn't type-safe? Not in any meaningful sense of the word, because to get this unsafe behaviour you have to deliberately make use of a function for which the only documentation is "Not for the casual user".

And yet the loophole exists.

Re:Argh!

[ajs]

Don't knock Tk. Tk applications (as from my original post) don't scale because of Tcl, but I have to say that Ousterhout did an awesome job on Tk, and influenced, among others, the development of Qt, Gtk+ and Java's various widget sets.

The canvas widget from Tk was so good that many later widget sets borrow the code directly (the "GnomeCanvas" is a direct descendant, though it may have been re-written (at least once) by this point).

I think TCL was a great plugin-commandline tool and wonderful for a config file syntax (the OpenMarket web server used it this way to great effect).

It was only when people strarted trying to treat a string-substitution system as a general purpose programming language that it started to become the abomination that gave me nightmares (you have not seen programming hell until you've seen a 100,000 line TCL program!)

Re:Argh!

[lkaos]

There are all sorts of polymorphism. At any rate, polymorphism doesn't automatic mean your dynamically typed. However, if all your objects are have the same base class, and you have common operators that work on that base class (like say, equals or compareTo), then you've eventually made dynamic typing.

Re:Argh!

[lkaos]

Ok, don't believe me. Run:

struct test a;

void *b =

There's an implicit cast.

Also, do:

int a = b;

There's an implicit conversion. If you look at the definition of strong/weak typing from Wikipedia:

Weak typing means that types are implicitly converted (or cast) when they are used. If we were to revisit the previous example:

Run the above code in C++ and you'll get errors. C++ is more strongly typed than C. I think you should read a little before you start saying such things.

Wayne

[Attar81]

I thought I had MONO once. Turned out I was just bored...

Here is somthing funny

[N8F8]

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?

[Animats]

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

credit to Mono team

[f00zbll]

recently I tried Mono and although I'm not convinced it is a viable long term option, since Microsoft will eventually go after Mono with lawyers, patents and copyright, they have made a lot of progress. Play with microsoft is like playing with matches while standing in a puddle of jet fuel. the smallest mistake will cause a huge explosion.

Oh hell, I'll bite

[DrZombie]

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.

Re:Oh hell, I'll bite

[jrcamp]

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.

Re:Oh hell, I'll bite

[dnaumov]

I won't. Since when was Firefox written in Java?

Re:Oh hell, I'll bite

[IWTB]

The Java GUI library is crap, and with rare exceptions (sweet sweet firefox)

Firefox wasn't built on Java, but C++ (core) & Javascript/XUL for the UI...

Because You Like It?

[reallocate]

Why use C#? Because you like the language. If you have a choice, why would you spend your time working with a language you don't like?

Thats odd..

[xagon7]

"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)?

Re:Thats odd..

[mmusson]

Pascal isn't that much different than C. It's still a low-level language. I think a better suggestion would be Lisp or Haskell.

Re:Thats odd..

[xagon7]

I must disagree. It may be low level, but it is nowhere near as terse as C or C++. It, as a language, is closer to VB than C/C++, yet not interpreted.

Re:What about java?

[Jon Pryor]

..and the class libraries be damned! Or?

Which class libraries? :-)

ECMA-335, which the grand-parent referenced, standardizes some of the class libraries. In particular, this file contains All.xml, which contains documentation for all namespaces, types, and type members (fields, methods, properties, etc.) for all standardized types.

What's actually covered? Enough to get the ball rolling -- I/O, XML, Reflection, Collections, Platform Invoke, etc. Basically, the .NET equivalent of the standard C library, and then some. (Well, much more than the standard C library, which lacks XML, Reflection, Collections.... But you get the drift.)

What isn't covered? Much more -- System.Windows.Forms, ASP.NET, ADO.NET, System.DirectoryServices, System.EnterpriseServices, etc. Much of this makes sense, as it doesn't already exist in a standardized form. Furthermore, much of it is specific to Microsoft Windows -- System.Windows.Forms is highly windows-specific, and will be "dropped" by Microsoft in favor of Avalon eventually, anyway. Other items have open-source equivalents -- LDAP can work for System.DirectoryServices.

To put it in perspective, ~295 classes are standardized, out of the ~7000 in .NET. (Number completely made up, but Mono has over 7000 .cs files in CVS, and Mono hasn't fully covered .NET either. Of course, many of those classes aren't public, and thus couldn't be used by external developers, but the number should be in the neighborhood...)

Whether this is "bad" or not is outside the scope of this response. :-)

Re:Forgot one...

[reallocate]

You sound like a grumpy engineer who decides what foods to eat based on their nutrient content and keeps asking everyone "Is That Really Necessary?"

It isn't important if C++ or any other language really did solve the same problems. Why should people use C++ if they don't like and and no one is paying them to use it?

Are you also deadset against every other language, too?

Considering the fact that almost everything in Linux and the opn source arena is a knock-off of something else, accusations of "copying" ring loud and false.

Tried SharpDevelop just today.

[marcelix]

SharpDevelop looks cool: cool gui, integrated NUnit, cool TaskList.. Importing VSNET2003 solutions worked OK, except few problems with embedded resources... I have high hopes for SharpDevelop. VSNET is still better but has shitty upgrade cycle - so we'll see what the future brings. :-)

Re:Why I think this is useful

[Kalani]

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

That has got to be one of the most irritating navel-gazing pieces I've seen on Slashdot, ever.

Hehe...

[Jugalator]

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

No advantage of C# over Java

[Axe]

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? There is nothing new there.

Re:No advantage of C# over Java

[iggymanz]

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.

Re:No advantage of C# over Java

[Axe]

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.

Re:No advantage of C# over Java

[iggymanz]

sure, the JVM will *run* on a 64 bit machine, but within the JVM it's a 32 bit world: it's a 32 bit animal. there is a project to develop a 64 bit JVM ongoing

Re:No advantage of C# over Java

[Sunspire]

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. The most important difference, on both Windows and on Linux, is the fact that some application is written in C# won't be broadcasted to the users. You want application "foo", mono gets pulled in a dependency like any other library or runtime. You launch "foo" and the program comes up with a native GTK#/SWF GUI. It's a fundamentally different outlook than with Java, which continually jumps in your face "this app is written in Java!" either explicitly (as if the user gives a damn) or because of the one hundred little things that are off even when using SWT in Eclipse. NET/Mono will just be a dependency, like the VC++ runtime before it and the VB runtime before that. It's a huge cultural difference: "Java Powered!!!1!" vs "I guess it's written in C#... or something." I was playing around with the NASA World Viewer application featured last week on Slashdot, only later did I find out it was written in .NET on this site. There's just no way to tell.

Mono apps on Linux or Windows won't come in some funky .NET specific container. You'll install the software exactly as you always have, for example by using RPMs via apt-get or yum. It might seem like a small detail, but it's actually a huge deal from the end users point of view because nothing changes. On a pristine installation of Fedora I issue "yum install monodevelop" and then "monodevelop" and lo and behold the app starts. Mono does its work quietly in the background, something Java has never achieved.

The JRE is an alien piece of software in Linux land. Even after you install the official RPM "java" produces a "java: command not found". Even as a developer I don't want to deal with that sort of shit these days if it can just be automated. There's just been no thought given to end user experience and it shows throughout the whole platform.

All these points make Java a horrible system for desktop Linux apps, and Mono on par with existing systems. Then when you add in all the niceties of working in a managed language, you've got to at least give Mono a good look when deciding what to use for your next Linux app.

Mono's 100% open source. Dismissing it right from the start just because it has its origins with MS is just stupid. The situation is completely analogous to MS SMB vs Samba. Even in an all Linux shop you're likely to find Samba in use because, frankly, NFS for the longest time has been a real piece of shit and is only recently worth using on Linux.

Re:No advantage of C# over Java

[LizardKing]

The 32 bit space & allocation limits of the JVM

Ah, more marvellous FUD from the Slashdot "elite". Java was written with 64bit systems in mind (don't forget - oh sorry, this is probably news to you - that Sun were one of the first to market with 64bit systems in the mid 1990's).

Re:No advantage of C# over Java

[iggymanz]

no elite or FUD here, but if you read the specs for the java vm found in pre-1.4 it indeed uses a 32 bit address space for its internal pointers. IBM and Sun have released the 64 bit (internal) JVM, but I've yet to hear they are production grade. You might also be interested to know that while Sun boxes with UltraSparc 1 chips were 64 bit capable, the Solaris 2.5 and 2.6 were not true 64 bit OS (I have an Ultra 170e which triple boots 2.6, 7 and 8, btw). Not until Solaris 8 (which includes both 32 and 64 bit kernel you have the choice of booting) did they get *most* of the 64 bit issues ironed out, and you can read all about the remaining problems in their online doc site.

Re:No advantage of C# over Java

[Axe]

You are indeed do not know what you are talking about. JRockit supports 64 bit addressing just fine. http://www.devx.com/Intel/Article/17457

Re:No advantage of C# over Java

[iggymanz]

cool, a BEA solution - but having no Itanium servers I must wait for UltraSparc and AMD production grade solutions from Sun, IBM, etc.

Re:Forgot one...

[Axe]

So let me get this straight: If I wanted to use Mono, I'd have to: relearn how to do everything I already know how to do in C++... rewrite all of my personal libraries... learn a completely new set of bugs in a new API....

Dude. If you have portable a)threading b)database connectivity c)GUI d)App servers working in you precious little C++ personal libraries setup you are either bullshitting us or smoking dope or do not know what you are talking about.

I have spent many years developing enterprise applications in C++. Even after they (finally. after many years of hell) got more or less portable standard implementations right, stabilized ABI etc etc. it still does not have what it takes to design middle tier stuff. That's where the money are.

you are free to wallow in your desktop/standalone apps (games?) /single platform world, but at least admit there are TONS of benefits of using Java (or .Net) platform for enterprise development (remember - that's where the money are).

Re:Forgot one...

[Bill Dog]

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

Reminds me of what I had read once on the creator of C++'s homepage: "Java isn't platform independent; it is a platform.". It certainly is from a developer's point of view. I'll probably get serious about Java some day, but that's exactly what's been stopping me -- I'm already extremely knowledgable and proficient on one platform, so switching is just taking a step backwards as far as productivity. My boss (a non-techy) envisions Java projects likely coming our way in the future, and I've told him I'll become proficient in it like I am in C++, but point out that it won't buy us anything, such as additional capabilities. I'll just be learning how to do all that I can already do right now, just in a slightly different language with a completely different set of libraries. Same goes for .Net.

patented libs in different part of build tree

[goon]

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

Re:Forgot one...

[Bill Dog]

Considering the fact that almost everything in Linux and the opn source arena is a knock-off of something else, accusations of "copying" ring loud and false.

Did you just say what I thought you said? Doesn't that make about as much sense as "he's been dishonest all his life, so you can hardly call him a crook."

Non-Trivial Case Please?

[Peaker]

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:Non-Trivial Case Please?

[tcopeland]

> trying to automagically use low-level languages
> as if they were high is doomed to a
> painful failure :)

Hm. Mostly, I agree - although I think scripting languages are frequently used in places where a memory leak or two isn't that important. For example, a cron job that creates some graphs can leak a few bytes without hurting anything.

> the programmer is freed from dealing with
> the pesky details of using a low-level language.

I think the programmer is freed from fiddling with pointers and mallocs and so forth to some extent. Not completely, but that's the nature of abstraction layers. One could make the same argument regarding C and assembly language...

Re:Forgot one...

[ahdeoz]

There are just tons and tons of libraries in Java that don't exist or are not cheap in C++.

Stay away from Java frameworks though. They're all bad. Not uniformly bad, but very few offer more functionality than roll your own + use the OS, stupid.

Java is easier for us dumb programmers though. Except I've been thinking of switching back to C++, just because it takes so long to type anthing in java (try a loop...iterator...enumerator ...cast... collection ...arrays of keys...pooling...hey how come my objects aren't getting garbage collected?) sure makes you miss simple destructors. If only C++ had the libraries AND DOCS that I needed. Oh, and because C++ is so much harder to do right for us (speaking only for the royal myself) I need someone else to write the framework that I could have written myself in Java.

C# is a little bit better than Java. At least it's less typing. And supposedly IKVM or J# will let me use all the Java libraries.

Maybe I should just go back to PHP.

Re:Forgot one...

[Axe]

but point out that it won't buy us anything, such as additional capabilities.

What do you do? What threading/GUI/networking/DB/utilities (such as regex) libraries do you use?

What development environment / automated testing /build environment?

In each of this areas Java will bring rather larger productivity gains. It is not just code. It is things like automated testing frameworks, ANT, 3rd party libraries working much more reliably.

I am not a big fan of Java, but our team migrated to it and advanatages are numerous and fairly obvious. It is quite possible, though, you do not care about any of it.

Re:Notebook or Handbook?

[BitwizeGHC]

A Developer's Back of the Envelope, perhaps?

I'm reminded of a series of booklets Radio Shack used to sell, back before it sucked, called "Engineer's Mini-Notebook". Written in a draftsman's block-print hand, they contained schematics and explanations of fun electronics projects to try -- all of the parts, of course, available from Radio Shack. I still have two or three of these.

These days you can't buy anything much more wireheadish than gold-plated audiowank cable.

Re:What's funny

[LizardKing]

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

>C# is a Java clone, while .NET is a JFC clone. Of course, Java and the JFC was inpsired by Objective C, NeXTstep and Smalltalk, but at least they weren't a blatant attempt to make an incompatible version of something just for monpololy preservation.

Re:Forgot one...

[LizardKing]

If you have portable a)threading b)database connectivity c)GUI d)App servers working in you precious little C++ personal libraries setup you are either bullshitting us or smoking dope or do not know what you are talking about.

Well ...

1. Threading - pthreads.
2. Database connectivity - libdbi and 101 variations thereof.
3. GUI - GTK+, Qt, WxWindows, etc.
4. App servers - CORBA, RPC, etc.

Most of these are admittedly C based, or available for C, but then real programmers don't bother with falsh in the pan stuff like .NET. Remember, .NET and C# is only relevant until MicorSoft find it's time to get you to upgrade (and deprecating your existing language or platform like VB or Fox is as good an incentive as they come).

ISO reference

[j.leidner]

ISO/IEC 23270:2003 Information technology -- C# Language Specification

--
Try Nuggets , the mobile search engine. We answer your questions via SMS, across the UK.

Re: sweet spot

[oodl]

"i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages."

You might want to check out the Dylan programming language which can be efficiently compiled to code that performs at C-like speeds. When programming in Dylan, you don't have to add any type specifiers unless you want to. If you do choose to add type specifiers, the compiler will use them for both optimization and verification purposes. In practice, you often only add type specifiers for the parameters of methods. The compiler is smart enough to type-inference the rest of the types within the method, so there's often no performance gain to be had by specifying a lot of typing info.

Re:What about java?

[MemoryDragon]

Which I would consider a totally idiotic statement since C# basically is a clone of java with a few language features added and a class library, not yet as extensive as Java. So tell me, where do you think the speed improvement comes from, which language feature, which library feature gives you the speed advantage?

Re:Forgot one...

[reallocate]

Uh, no. The post lambasted Mono as an unnecessary ego-driven piece of work that solves problems that were solved by earlier tools.

If one applies that logic to Linux, it ought not to exist.

Re:Forgot one...

[Axe]

Portable? Maintainable? How often you needed to redistirbute all libraries due to incomaptible ABI changes in your C++ compiler?
Allow me to laugh in you face. Ha ha ha.
Now it felt better.
CORBA, you say? Pthreads? Real programmers?
Cool. Whatever you say, real programmer.

P.S. I did code in C++ while people were still using FORTRAN. Still do. DO not miss when I do not.

C# Rocks

[Pedrito]

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.

Delphi weak point: collections

[Latent Heat]

I use Delphi for most of my stuff, but the weak point has to be thin support for collections. There is a list object (works like Java in that you store stuff as object references and have to cast the reference you get back), but it requires linking in the VCL -- what if you are doing a console app or your own Windows classes?

Re:Forgot one...

[GenSolo]

Why should people use C++ if they don't like and and no one is paying them to use it?
Well, I must ask, if you don't like C++, why would you use Java or C#? Yes, every language can be used to solve the same problems as every other language, but what innovative improvements over C++ did Java or C# make that should convince someone who does like C++ to use them? (Honestly, I'm asking because I'm debating whether or not to try out C#/Mono.)

You're mixing up the terms, again.

[Estanislao Mart�nez]

If you violate type rules in Java, you get (at worst) a well-defined runtime error.

That doesn't sound very static to me.

A good informal definition of strong typing (note I did not say "static") is that all type errors are caught. A language with a strong static type system catches all type errors at compilation time; a language with a strong dynamic type system catches them at runtime.

In C and C++, many type errors are caught at compilation time, but many programs with type errors are accepted by correct implementations, and no mechanism catches them at runtime. Thus, they are weak static languages.

Java is strongly typed, and has both static and dynamic typing. The compiler catches many type errors, and the runtime system catches every other type error.

Re:You're mixing up the terms, again.

[lkaos]

A good informal definition of strong typing (note I did not say "static") is that all type errors are caught.

Well, I kind of don't really like this definition very much. The problem with a language like C is definitely different than one like C++. In C, types are implicitly converted between each other. In C++, this isn't the case. However, for performance and backward compatibility C++ offers mechanisms such that you can perform explicit conversions between types that can result in undefined behavior in error situations.

Now, undefined behavior in an error caused by an explicit type conversion isn't bad in my mind. Considering that an explicit type conversion is really just an operator (in fact, it's an overloadable operator in C++) it really doesn't matter what the semantics are here.

Java is strongly typed, and has both static and dynamic typing. The compiler catches many type errors, and the runtime system catches every other type error.

Thank you. This is the most intelligent thing I've seen in this conversation so far. My original post was based on the characterization that Java was a "strong staticly typed" language and C++ was a "weak staticly typed" language.

I think you'll agree this statement is incorrect.

You're both making a fundamental mistake.

[Estanislao Mart�nez]

Java is both statically and dynamically typed. Every identifier in a source program must have a type, and all objects and methods carry type information that's checked at runtime.

The deal is that the Java static type system is not powerful enough to figure out when an identifier that's declared as type A is bound to an object of a subclass of A. This is where casts enter into the picture; in this case, dynamic typing ensures that casting does not break strong typing.

Re:Forgot one...

[Bill Dog]

What do you do? What threading/GUI/networking/DB/utilities (such as regex) libraries do you use?

We do scientific 3D modeling with OpenGL in C++ on Windows (we have some other stuff that runs on Solaris, that I'm not involved with).

* Threading - As a company we've standardized on pthreads. In the past I've used Win32 API calls for threading.
* GUI - MFC and the Win32 API. It looks like the company is currently considering switching to Qt.
* Networking - Winsock. After calling the non-standard WSAStartup(), you can eschew the other WSA* calls and program it BSD socket style.
* DB - MS provides the nice high-level but robust ADO.
* Utilities - Haven't had a need yet to do regexp'ing in C++. But, for example, for XML, Apache's Xerces C++ implementation of the SAX2 parser seems extremely fast and I've had no reliability issues with it. MS provides one as well.

You see, as with Java, typically the platform provides the facilities you need (if the entity, incidently often commercial, behind the platform wants developers to write for it!).

What development environment / automated testing /build environment?

Visual C++ 6.0 is very nice. The first place I worked at had makefiles to run nightly builds with VC++'s command line tools (which, incidently is what the IDE drives). And as with everywhere I've worked so far, developer unit testing is rather informal. QA has automated testing tools.

In each of this areas Java will bring rather larger productivity gains. It is not just code. It is things like automated testing frameworks, ANT, 3rd party libraries working much more reliably.

Here's where you may be showing your age/inexperience. Do you think we all used to just sit around doing nothing, waiting for Sun to invent Java, so that we could finally be productive and accomplish something? VB'ers have been cranking out business apps hyper-productively for years.

Re:Forgot one...

[GenSolo]

Thanks for the info. Since I tend to use STL vectors over arrays (and thus get bounds checking), I use boost.org's smart pointers for most of my heap-based memory management (which isn't much, comparatively), and if I'm integrating w/ C++ code not written to use exceptions, you lose C#'s gain in that area anyway, it appears that C# offers me very little over C++ with decent libraries. Thanks again.

Strong Typing vs Type Safety

[cakoose]

In strongly typed languages, type safety is enforced, with no loopholes. Both ML and Java meet this criterea.

You are confusing typing strength with type-safety.

For example, you can have a crash-proof implementation of BF. Does that make BF type-safe? Yes; the type system is so pathetic that it's trivial to enforce type safety. Does it make BF strongly typed? No, because the type system doesn't do a good job of accurately describing the values you compute on. Tcl is also type-safe, but, again, the type system is weak (strings and lists are all you get).

Perl is often cited as a weakly typed language because strings and numbers are easily interchangeable. But this doesn't make Perl type-unsafe. Type-safety is enforced; it's just that there is a type called "scalar" that can handle both strings and numbers by design. Perl is weakly typed because many other languages make the distinction between strings and numbers and therefore more accurately describe values.

Type-safety means you cannot escape the type system. Strong typing means that your types are very precise descriptions of your values (relative to other languages).

Some examples:

Language | Safe | Typing Strength
Tcl . . .| Yes. | Pathetic.
C . . . .| No . | Weak. Lacks subtyping, among others.
Old Java | Yes. | Medium. No parametric polymorphism.
New Java | Yes. | Strongish.
C++ . . .| No . | Strongish.
Haskell .| Yes. | Strong.
Epigram .| Yes. | Insanely Strong.

BTW, Python shouldn't really be considered strongly typed. The typing is weaker than Java's. Method invocations and field accesses are performed through string lookup.

class ElevatorButton:
. . def Press()
. . . . CallElevator():

class BellyButton:
. . def Press():
. . . . Giggle()

// weakly typed:
x = GetElevatorButton();
x.Press();

// strongly typed (not real Python):
x = GetElevatorButton();
x.[ElevatorButton]Press();

The strongly typed version ensures that you're invoking the method you think you're invoking instead of invoking a method that simply has the same name. Python will not notice an error if GetElevatorButton() returns a BellyButton instead because method invocations are done by matching strings. Of course, the stronger typing doesn't really work well in a dynamically typed language. (Then again, dynamic typing is just a fad that will fade when people realize that what they really wanted was type inference).

Re:Strong Typing vs Type Safety

[be-fan]

What you call "type safety" is what wikipedia defines as "strongly typed." Using the strong/weak distinction to refer to type safety is the traditional usage of the terms.

What about the book?

[StrawberryFrog]

How about talking about the book specifically, rather than mono in general for a bit. I've been playing with mono a bit, and have a book called "Mono kick-start" that I don't find to be much use. Is this book better? How?

I've written enough code for my toy project that now I want to put a gui on it, rather than just "self-testing by Console.Write". Problem is, I now want to do some custom drawing and I don't know GTK at all. Will this book help me?

Where, if anywhere, can I find a good API/class library reference for using GTK in mono on win32?

Re:Forgot one...

[LizardKing]

How often you needed to redistirbute all libraries due to incomaptible ABI changes in your C++ compiler?How often you needed to redistirbute all libraries due to incomaptible ABI changes in your C++ compiler?

Never. Mainly because the guts of most systems I've worked on have been written in C rather than C++. The only time that changes in the C++ libraries have bitten me (API rather than ABI) is when I upgraded gcc on Tru64 from 2.95.2 to 3.something. A few 'using namespace std;' liberally sprinkled in my source fixed things. Not as painful as switching from Java 1.0.2 to Java 1.1 ...

Re:Forgot one...

[reallocate]

Style, syntax, design, structure, etc., are at least as important as innovatory features in determining if a developer feels comfortable with a language. If someone can express his ideas more readily in one language than another, he's likely to choose it, all things being equal.

In truth, all languages solve the same set of problems, just in different ways. (I'm deliberately not including developer candy like bounds checking. These things can be implemented in any language.)

Funny you should say so :) .. C# is shorter

[Gopal.V]

[DllImport("libcurl")]
private static extern String curl_version();

works for me in C# ...

I hate JNI .. .NET's design is a little better - But I stick to good old GPL'd Portable.net for my .NET needs :)

Re:Forgot one...

[gillbates]

Considering the fact that almost everything in Linux and the opn source arena is a knock-off of something else, accusations of "copying" ring loud and false.

The major contribution of Linux was that it brought the stability and functionality of UNIX to the PC desktop for those who couldn't afford the expensive UNIX workstations. In PC-Land, it was a tremendous improvement over DOS and Windows, even if it was a copy of UNIX.

But neither .NET nor Java nor Mono offer anything substantially better than C++. Why bother bringing .NET to Linux (Mono), when gcc already does a better job? It would be akin to me cloning Linux and expecting everyone to use my "special" version of Linux just because I released it under a different license.

Re:What about java?

[MemoryDragon]

Acutally no, there is no speed improvement in this regard, The JavaVM currently still is a tad faster, it does better runtime optimizations as the CLR. Where .Net can really shine is things where it can hook directly into the underlying windows dlls. Which is rather easy because, .Net is a code once, run on some Windows versions thing. Wheras java has to abstract in many areas.

As for the other stuff. .Net added autoboxing (already in java, 1.5 is stable since today), foreach also in java since 1.5 and the in my opinion really good meta data stuff. As for the namespaces I dont see to many advantage. Well you also have the attributes, which basically is a problem if you dont know if they are attributes because you cannot see it directly. That might be your argument, but face it buddy, ever modern ide, generates the setters and getters automatically in java, you dont code them anymore.
The coding speed is improved mainly by the autoboxing foreach and the attributes, but those are handled already.

Operator Overloading, well a matter of taste, I am not a big fan, coming from the C++ side I know about the problems this stuff can cause, if not used wisely and thoughtful.

Re:Forgot one...

[reallocate]

Whether or not .NET or java or Mono offers anything better than C++ is akin to asking if C++ offers anything better than C, or if C offers anything better than assembly. Or, if a peach pie offers anything better than an apple pie.

People choose apple over peach because they prefer apple. Some people choose peach. Some people choose C++ because they like it. Some people can't stand C++ and will never use it. Some people will choose Mono because they like it. Some people won't.

Linux is an improvement over DOS and DOS-based Windows, and less of an improvement over Windows 2000 and XP. But many people acknowledge that Linux is technically superior to Windows and still continue to use Windows because they like using Windows more than using Linux The same logic applies to languages. If two languages can get the job done, why not use the one you enjoy? Why use the language that fights you every step of they way?

And, if you want to clone Linux and release it, no one is stopping you. There's no reason why you should not do what you want. No one is keeping score, you know.

~DefinitiveSource(Wikipedia)

[cakoose]

I wouldn't consider the Wikipedia to be a definitive source, especially for such an often-confused term. For all I know, you could have written that entry. Things I "learned" from that entry:

• "Suppose that a strongly typed language (like Pascal) didn't have garbage collection..."
• "...garbage collectors are best implemented in languages that allow pointer arithmetic."
• Garbage collection is the only form of automatic memory management.

Look at entry on typed and untyped languages. It says that Perl is weakly typed. But you can't escape the Perl type system and cause a crash which means (by the other entry's definition) that it is strongly typed. So, apparently, some Wikipedia contributor doesn't agree that the two terms are equivalent.

Not really preferences

[gillbates]

Well, if it's only a matter of preferences, then there's really no point in discussing it.

But C++ did offer considerably more than C, and C more than assembly. C wasn't object oriented, and assembly wasn't easily readable.

So I would have expected the whole Java-.NET-Mono thing to offer something considerably better than C++, but they didn't. In fact, the did just the opposite - they took features away whilst making the language slower.

It isn't a matter of preferences, but performance. .NET, and Mono are offering 1970's era performance and development times on 21st century hardware. Consider the categories in which they don't excel:

• Development time - Visual Basic and TCL are faster.
• Security - Java is more secure.
• Runtime speed - pretty hard to beat C/C++, and can't touch assembly.
• Portability - .NET doesn't run on UNIX; Mono could be killed by Microsoft with patent encumberances.
• Functionality - C++ already has a plethora of useful libraries that we don't need to learn again.
• Utility - C/C++ can be used to write anything from OS kernels and drivers to middleware apps.

Mono and .NET don't excel in any of these categories. Granted, it doesn't stop you from using it, but why would you go through the trouble to build a new language if it didn't excel in even one of these categories? The issue isn't with the people who use it, but rather why it was built in the first place. It isn't innovative. In fact, it's an embarassment; a metaphorical grabbing at Microsoft's coattails.

Mozilla gives me tabbed browsing - something MS has yet to discover.

Linux gives me a stable OS - at the time of its release, Windows couldn't run for more than 90 days without crashing.

GCC is probably the best compiler I've seen to date - it would take Microsoft years before VC++ could generate faster code.

And then there's Mono: for those who hate Microsoft so much that they run Linux, yet love MS software so much that they must clone .NET.

Re:Not really preferences

[reallocate]

Well, of course, it's all about preferences. Even if your employer compels you to use a language you hate, you still have the choice to seek employment, and another language, elsewhere.

In your case, you've listed your preferences. Other categories exist, to which other people may attach more importance. In pariticular, I'd argue that a developer should first seek a lanuage that allows him to comfortably and rapidly express his ideas. After all, that's why they're called languages. Speed, portability, utility, etc., are only academic issues if the language stands in the way of the developer saying what he wants to say.

Obviously, then, this is a very individual thing. Some will find C++ expressive, others will be hobbled by it. Some will toss of brilliant programs in Visual Basic, while others stare at a Visual Studio display and wonder what happened to the editor.

So, whether or not Mono or .NET excel in anything is not important. What's important is a developer who excels, regardless of the language.

As for using Linux because you hate Microsoft... Well, I've been a Linux user for years, but that's because the first OS I used after DOS 2.1 was Unix. I've never understood why people would let ideology determine their choice of software. It makes no more sense to me than letting political opinion determine your choice of pliers.