[Mono-list] evangelizing mono

[Jonathan Pryor]

On Sat, 2004-02-14 at 15:00, Jeffrey McManus wrote:
> Hey team,
<snip/>
>  - Do you have good evangelism tactics for Linux developers who evaluate
> Mono and find it somehow "un-Unix-like"?

I don't, except to answer their questions...

>  - Is there a technical answer to the "mono my.exe" command-line objection?

Yes.  There are two solutions:

1)  Use a shell script which calls the actual program.  I've found this
script to be useful:

	#!/bin/sh
	# Starts a CIL program whose name is patterned after the
	# filename of this script.  The CIL program executed is
	# "$0".exe.

	file=$0

	# If file is a symlink, find where it's pointing to
	if [ -L $file ] ; then
		if ! (readlink -f "$file") > /dev/null 2>&1; then
			echo `basename "$0"` ": missing required program readlink!"
			exit -1
		fi
		file=`readlink -f "$file"`
	fi

	exec mono "$file.exe" "$@"

2)  Use the Linux BINFMT_MISC kernel module.  Then you can remove the
".exe" extension on the binaries, and still execute the programs
normally.  See: http://www.atoker.com/mono/, and search for
BINFMT_MISC.  In particular, the "mono.init" script can be used to set
this up.

>  - Is there an elegant solution for distributing the Mono framework onto
> client machines today?

Other than RPM and Debian Packages?  *Is* there a more elegant way to
distribute *any* software? ;-)

(Yes, this is a biased view, but Linux binary package management is
fairly elegant, especially when using apt or yum systems.)

However, this will depend upon what your client machines are.  Does mono
support them?  Does Mono support them *well*?  (Mac OS X isn't supported
well at this time, and people frequently have problems building Mono on
Windows...)

>  - Are there examples of functioning high-performance client/server apps
> running on Mono today?

I'm not aware of any, but I wouldn't know, either.

<snip/>

<digression type="major">

However, with regards to your particular situation, I think you might be
going about this the wrong way.  Mono may be the perfect choice.  It
might not be.  And trying to get all developers, both internal and
external, to agree to a single choice will be difficult.

Which is why you shouldn't be making it. :-)

This is *precisely* what SOAP and Web Services are for.  What the client
is implemented with, and what the server is implemented in, is
immaterial as long as they both understand the same transport: SOAP. 
This would permit your developers to continue developing in a language
they're comfortable with now (C++, apparently), and change strategies
tomorrow without breaking any existing clients.

You have the current scenario: "Maintainability and developer
productivity is a big deal with custom eBay clients that use the API
because eBay changes so frequently."

There are two solutions: choose a more efficient development
environment, which you seem to be advocating.  While possibly an ideal
solution, it is entirely possible that the new environment can't/won't
be supported in all the areas current programs operate, or future
required platforms.  Furthermore, the more custom clients you have, the
more work you will need to do if something changes, and just emphasizing
a more efficient development environment will likely also emphasize
making changes that will require updating all the existing clients,
"because it's easy, so why not?"

The other solution is to do some up-front design.  It sounds like you've
had several designs so far, so I would hope that your developers
understand the problem domain sufficiently to create a decent design. 
With that design, decompose the system into layers, and pick a
communication strategy between layers.  As long as the interfaces
between layers are consistent, the actual implementation can change ad
hoc, and (done properly) no existing code will need to be touched. 
There's a reason that the networking protocols have remained consistent
for nearly (over?) 20 years, and it's not because of an "efficient
development environment." :-)

This can be done with the efficient development environment.  But this
also allows you to make concessions to interact and integrate with
environments that might not support Mono (or the chosen environment). 
It can also allow quick prototyping -- prototype the GUI in Python, for
example, to see what works, before re-writing in some other language. 
With decent interfaces, Python will be able to function within the
actual working system, and you may well find that Python is sufficient.

Developer familiarity is also key.  C# may be an easy language, but
there's still a learning curve associated with it, and it may be more
efficient to let the developers stay within their more familiar
language.  There's no reason that C++ can't be a decent development
environment, AS LONG AS modern C++ techniques are used (templates,
exception-safe code, NO POINTERS -- that's what std::vector and
std::auto_ptr is for, etc.; failure to do so will lead to madness, which
I've had to deal with far too often in "legacy" code...).

The proper solution is *always* a decent design.  Getting a decent
design can be difficult, I'll freely admit, as it requires experience in
the problem domain.  But if your developers don't have enough experience
in the problem domain by now, after making (apparently) frequent
code/design changes to the entire system, you have larger problems than
an inefficient development environment.

</digression>

 - Jon