IronPython-0.6 is now available!

[Neuruss]

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

[Ivan Voras]

Neuruss wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

This is great news! It could be an answer to those who need 'compiled'
python[*]. And cross-platform too![**]
[*] Yes, there's py2exe, and .net means IL, but it's an .exe!
[**] .net for windows, mono for unix systems :)

Btw. has any serious python-lover tried C#? I was sceptical, it comming
from Microsoft, but I'm reading a book about it now ("Programming C#"),
and I'm getting really impressed - it could be a very productive
language, and speedy also.

--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't
you understand?

[Peter Hansen]

Ivan Voras wrote:

Btw. has any serious python-lover tried C#? I was sceptical, it comming
from Microsoft, but I'm reading a book about it now ("Programming C#"),
and I'm getting really impressed - it could be a very productive
language, and speedy also.

In what way do you feel C# is significantly different than Java?

As near as I can figure, those who find Python has significant
advantages for many applications over Java and C++ will likely
feel the same way about C#, only more so. Isn't it basically
a highly MS-centric remake of Java, but missing the very
cross-platform nature which has served Java (and Python) best?

-Peter

[Derek Thomson]

On Thu, 29 Jul 2004 01:27:28 +0200, Ivan Voras <ivoras@__geri.cc.fer.hr> wrote:

Btw. has any serious python-lover tried C#? I was sceptical, it comming
from Microsoft, but I'm reading a book about it now ("Programming C#"),
and I'm getting really impressed - it could be a very productive
language, and speedy also.

This isn't entirely unlikely. Microsoft actually involved a number of
non-Microsoft experts in the field of language and "virtual machine"
design in the development of some of the .NET technologies, such as
the CLR.

I haven't yet found the time to look at any of this stuff in detail,
but I will, and it wouldn't surprise me at all to learn that it was
really quite good in many respects - MS didn't just forge it all from
the ground up in total isolation, ignoring all that had gone before,
hoping to get it working right in the 3rd release.

dt.

[flacco]

Neuruss wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

from the ironpython web page:

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

[Derek Thomson]

On Wed, 28 Jul 2004 23:33:33 -0400, flacco
<fl*******@spambadtwilight-systems.com> wrote:

Neuruss wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

from the ironpython web page:

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

I saw that - does it mean there is interest in Python at Microsoft, I wonder?

dt

[xtian]

lu****@gmx.net (Neuruss) wrote in message news:<27*************************@posting.google.c om>...

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

http://www.ironpython.com

This snippet's pretty exciting!

"""
....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'd love to see Python as a fully-integrated .Net language - worries
about Microsoft evilness notwithstanding.

xtian

[Ville Vainio]

>>>>> "xtian" == xtian <xt***@toysinabag.com> writes:

xtian> I'd love to see Python as a fully-integrated .Net language
xtian> - worries about Microsoft evilness notwithstanding.

<aol>Me too</aol>.

Microsoft appears to be doing a good job undermining Java. It's hard
to imagine Sun starting to sponsor a Python-for-Java-platform
project. Microsoft is still the underdog in the VM platform business,
so expanding the reach of the platform makes perfect sense.

I totally symphasize with those who worry about the possibly
encumbered status of Mono, but I won't mind if/when .NET manages to
bring Sun and Java down a notch, what with their arrogance and
one-language-fits-all approach.

--
Ville Vainio http://tinyurl.com/2prnb

[Ganesan R]

>>>>> "Neuruss" == Neuruss <lu****@gmx.net> writes:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work. http://www.ironpython.com

This is exciting news. Has any one tested this with mono 1.0 on Linux?
Simple things work, but I am not able to define a new class.

=========
$ ./IronPythonConsole.exe

class Test:

.... pass
....
System.NullReferenceException: Object reference not set to an instance of an object
in (unmanaged) (wrapper managed-to-native) System.Reflection.MonoField:GetValueInternal (object)
in <0x00004> (wrapper managed-to-native) System.Reflection.MonoField:GetValueInternal (object)
in <0x00012> System.Reflection.MonoField:GetValue (object)
in <0x00046> IronPython.Objects.module:__getattribute__ (string)
in <0x00032> IronPython.Objects.ModuleDictionary:get_Item (object)
in <0x0002c> IronPython.Objects.Frame:GetGlobal (string)
in <0x00037> input_0:Run (IronPython.Objects.Frame)
in <0x001c5> IronPythonConsole.IronPython:DoInteractive ()
==========

Ganesan

[Bruno Desthuilliers]

Ville Vainio wrote:

>>"xtian" == xtian <xt***@toysinabag.com> writes:

xtian> I'd love to see Python as a fully-integrated .Net language
xtian> - worries about Microsoft evilness notwithstanding.

<aol>Me too</aol>.

Microsoft appears to be doing a good job undermining Java. It's hard
to imagine Sun starting to sponsor a Python-for-Java-platform
project.

Which BTW already exists...

Bruno

[Ville Vainio]

>>>>> "Bruno" == Bruno Desthuilliers <bd*****************@free.quelquepart.fr> writes:

Microsoft appears to be doing a good job undermining Java. It's
hard to imagine Sun starting to sponsor a
Python-for-Java-platform project.

Bruno> Which BTW already exists...

Yes, of course, completely without support from Sun - and it's
starting to fall behind current CPython in features as well. Sun
wouldn't really need to do much - just donate some resources to get
Jython to match current CPython in features, and make a press release
or two mentioning that Sun is seriously supporting the use of Jython
on Java platform.

It would be a minimal bet as far as their resources are concerned, and
the fact that they are not doing it suggests that it contradicts their
stategy of force feeding their COBOL variant on everyone.

Sometimes Sun Just Doesn't Get It. I would love to see IBM steal the
Java leadership away from Sun, which they speculate could happen if
Java was open sourced...

--
Ville Vainio http://tinyurl.com/2prnb

[A.M. Kuchling]

On 29 Jul 2004 14:35:27 +0530,
Ganesan R <rg******@myrealbox.com> wrote:

This is exciting news. Has any one tested this with mono 1.0 on Linux?
Simple things work, but I am not able to define a new class.

Edd Dumbill also reports getting a simple program to work:
http://usefulinc.com/edd/blog/conten...ronpython/read

I'd bet that if it's just a matter of a few bugs preventing IronPython from
working,the Mono developers will fix those bugs pretty quickly.

--amk

[Michel Claveau, résurectionné d'outre-bombe inform]

Hi !
Very fun ! Thanks.


But :

I've decided to join the CLR team at Microsoft beginning on August 2.

Is Jython (futur) dead ?

[Marek Baczyñski]

Dnia Wed, 28 Jul 2004 19:53:48 -0400, Peter Hansen napisa³(a):

As near as I can figure, those who find Python has significant
advantages for many applications over Java and C++ will likely
feel the same way about C#, only more so. Isn't it basically
a highly MS-centric remake of Java, but missing the very
cross-platform nature which has served Java (and Python) best?

Isn't it MS-centricity that serves C#? IMHO it's so popular (relatively)
because MS backs it.

--
Marek Baczyñski :: UIN 57114871 :: GG 161671 :: JID im******@jabber.gda.pl
He who knows best best knows how little he knows. -- Thomas Jefferson

[Peter Hansen]

Marek Baczyñski wrote:

Dnia Wed, 28 Jul 2004 19:53:48 -0400, Peter Hansen napisa³(a):

As near as I can figure, those who find Python has significant
advantages for many applications over Java and C++ will likely
feel the same way about C#, only more so. Isn't it basically
a highly MS-centric remake of Java, but missing the very
cross-platform nature which has served Java (and Python) best?

Isn't it MS-centricity that serves C#? IMHO it's so popular (relatively)
because MS backs it.

That's exactly what I thought, but clearly the OP thinks
differently or (it seems to me) he wouldn't be asking the question
he asked (or in the way he asked it).

-Peter

[A.M. Kuchling]

On Thu, 29 Jul 2004 08:53:43 +0200,
Michel Claveau, résurectionné d'outre-bombe informatique <un************@msupprimerlepoint.claveauPOINTco m> wrote:

I've decided to join the CLR team at Microsoft beginning on August 2.

Is Jython (futur) dead ?

Jim Hugunin hasn't worked on Jython in years, so this doesn't affect
Jython's status at all.

--amk

[Neuruss]

I'm very excited with this project!
And the fact that Jim will be working within the CLR team in Microsoft
only gives me hope about its future. Jim already probed his talent
when he created Jython, and now, working with Microsoft the results
can't be bad...

I downloaded IronPython and played with the windows forms example and
it is miles away from an equivalenet c# program. It's increddible! All
the simplicity of Python with the power of windows forms, just a small
exe with all you need...

I just can't wait for a stable release.

[Alan Kennedy]

[Bruno Desthuilliers]

Microsoft appears to be doing a good job undermining Java. It's
hard to imagine Sun starting to sponsor a
Python-for-Java-platform project.

Which BTW already exists...

[Ville Vainio] Yes, of course, completely without support from Sun - and it's
starting to fall behind current CPython in features as well. Sun
wouldn't really need to do much - just donate some resources to get
Jython to match current CPython in features, and make a press release
or two mentioning that Sun is seriously supporting the use of Jython
on Java platform.

It would be a minimal bet as far as their resources are concerned
I'd never thought of it that way, but now that I do, I couldn't agree
more. The comparison between the way Sun treats jython and Microsoft
treats IronPython couldn't be starker.

In Sun's defense, it is important to note that good things(tm) have
come from the Java Community Process, e.g. a very well-designed,
robust, and efficient multi-platform non-blocking IO API.

But the problem is that the java community seems transfixed by the
notion that it is good idea to keep building new languages. Witness
the inapproriate use of XML-as-scripting-language in java tools, e.g.
ant. And then there's the JCP effort to develop Groovy, a completely
new scripting language that "includes features found in Python, Ruby,
and Smalltalk, but uses syntax similar to the Java programming
language". I don't understand why they can't just be happy with the
existing scripting languages on the java platform: Is javascript not
java-like enough? Is (p|j)ython not rock-solid enough? Obviously not:
they keep trying to reinvent the wheel.

I guess for Sun and the java community in general, it's a case of
purity beats practicality.

So those pythonic folks at Microsoft, for whom practicality beats
purity every time, will further extend their reach/mindshare in the
development community. Which won't bother me in the slightest: I wrote
a C# webservice for a customer's customer there a few months ago, and
it was a surprisingly productive experience. Python on that platform
will be awesome.
Sometimes Sun Just Doesn't Get It. I would love to see IBM steal the
Java leadership away from Sun, which they speculate could happen if
Java was open sourced...

I'm feeling a big change in the wind, with "dynamic languages"
certainly being flavour of the month/quarter/season. Technology
leaders across different technology areas are writing about their
positive python experiences: Tim Bray (XML) is dipping his toe in the
python waters, Steve Vinoski (CORBA) seems tired of the brittleness of
static languages for building distributed object systems, and is
trying his hand with twisted python, Jon Udell is speaking at python
conferences now, etc. Hopefully Sun will wake up and smell the
pythonic coffee soon ......

samuele-pedroni-for-pope-ly y'rs

--
alan kennedy
------------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/contact/alan

[Neal D. Becker]

After reading a tutorial on c#, I see immediately that it has all the
features that I disliked in Java.

1) Everything is derived from "Object"
2) Some things have value semantics, some have reference
3) No multiple inheritance

I'm not sure about 2 others:

4) No serious generic programming support
5) Only OO supported:

(This is HelloWorld is C#. Is this actually different than HelloWorld in
java???)

using System;
public class HelloWorld
{
public static void Main()

{
// This is a single line comment

Console.WriteLine("Hello World! From Softsteel Solutions");
}
}

[Alan Kennedy]

[Ivan Voras]

Btw. has any serious python-lover tried C#? I was sceptical, it
comming from Microsoft, but I'm reading a book about it now
("Programming C#"), and I'm getting really impressed - it could be a
very productive language, and speedy also.

[Peter Hansen] In what way do you feel C# is significantly different than Java?

As near as I can figure, those who find Python has significant
advantages for many applications over Java and C++ will likely
feel the same way about C#, only more so. Isn't it basically
a highly MS-centric remake of Java, but missing the very
cross-platform nature which has served Java (and Python) best?

IMHO, Microsoft have always been masters of the 80/20 rule: making it
very simple for users to do 80% of what they want, but leaving them
bending over backwards to do the last 20%. Practicality beats purity.

http://management.about.com/cs/gener...reto081202.htm

But I think MS have done a much better job with the .Net CLR ( == java
the virtual machine) and C# ( ~= java the programming language ). They
hired lots of clever people, asked them to come up with something
java-like, but (better|simpler). The result is, IMHO, quite nice: I
felt pretty at home writing C# pretty quickly, mostly because of my
java experience. There are a few differences that might feel quirky at
first, but they seem natural enough once you get used to them, e.g.
the physical location from which classes are loaded determining their
security priviledges.

And I think it's important to note that the MS.Net CLR is not the only
show in town. Novell backs the Mono project now, and they are a
considerable Microsoft competitor. There are still
highly-change-resistant organisations out there running Novell Netware
(remember that?): many of them skipped Windows completely, and are now
upgrading to Linux, which Novell now also sell through their
acquisition of Suse. So in the near future, commercial users will have
a choice of Windows/CLR.Net or SuseLinux/Mono to run their
C#/J#/Ironpython/(VB|J)Script/etc assemblies. So possibly some serious
competition lies ahead, deliberate attempts to introduce
incompatibility notwithstanding.

I see all of these matters as a huge validation of the concept of
software virtual machines, at a social and commercial level if not a
technical one. And of course python was doing virtual machines a long
time before any of these JVM/CLR upstarts, which explains why its so
stable, robust, efficient and excellent.

just-my-0,02-euro-ly y'rs

--
alan kennedy
------------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/contact/alan

[Tor Iver Wilhelmsen]

"Neal D. Becker" <nd*******@verizon.net> writes:

1) Everything is derived from "Object"
How can you not like this?
3) No multiple inheritance
MI is a crutch.
4) No serious generic programming support
Apparently coming in 2.0.
(This is HelloWorld is C#. Is this actually different than HelloWorld in
java???)

No.

[Christopher T King]

On Thu, 29 Jul 2004, Neal D. Becker wrote:

(This is HelloWorld is C#. Is this actually different than HelloWorld in
java???)

using System;
public class HelloWorld
{
public static void Main()

{
// This is a single line comment

Console.WriteLine("Hello World! From Softsteel Solutions");
}
}

Nope, looks just as ugly to me... ;)

[Cameron Laird]

In article <5d********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:

[simo]

flacco <fl*******@spambadTwilight-systems.com> wrote:

IronPython is currently at a pre-alpha stage suitable for
experimentation but not for serious development work.

Yeah, very pre-alpha from the few tests I did, but I'm very excited
about this, especially as it seems the Parrot guys have given up on
Python :-(
"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.
Hopefully IronPython will still be *developed* as opensource, or is
this release a last-ditch opensource version, before it is owned by
MS?

I think even I would be tempted to buy "Visual Python.NET" or whatever
it becomes, if it could make standalone CLR .exe's, especially if it
had wx# bindings not just WinForms/GTK#, but I'd prefer an opensource
effort (don't want the Linux/mono version to die).
"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."

I hope this doesn't mean abandoning Python for other scripting
languages.

I think Python on the CLR would be a very nice competitor to Java for
MS.

[Martin v. Löwis]

Neal D. Becker wrote:

Is this actually different than HelloWorld in java???
using System;
public class HelloWorld
{
public static void Main()

{
// This is a single line comment

Console.WriteLine("Hello World! From Softsteel Solutions");
}
}

Yes:
- It it not System.Console, but java.lang.System.out,
and java.lang is implicitly imported (not usinged)
- it is not WriteLine, but println
- it is not Main, but main
- the main function requires an argument (String[])

Regards,
Martin

[Martin v. Löwis]

Derek Thomson wrote:

I haven't yet found the time to look at any of this stuff in detail,
but I will, and it wouldn't surprise me at all to learn that it was
really quite good in many respects - MS didn't just forge it all from
the ground up in total isolation, ignoring all that had gone before,
hoping to get it working right in the 3rd release.

I have worked a lot with C# and .NET lately, and found two things:
- the VM is very well designed. It does not really work for languages
other than C#, though (and, yes: I believe that it does not work
well for Python either, despite IronPython's existance (*))
- C# is ok. There are a few unfortunate (IMO) hacks, like the notion
of delegates (which are the only callable objects), and the surprising
behaviour wrt. to interfaces and overriding (where functions in a
subclass won't implement an interface operation defined in the base
class unless that implementation is virtual), but all in all, I
can live with it.
- The IDE is great; MSVC's type-ahead interface (or whatever it is
called really saves a lot of typing an documentation lookup)
- The standard library is both huge and awfully, terrible, and a huge
hack.
There is API for nearly any aspect of the system, but many aspects
are ill-designed, apparently in an ad-hoc manner - the entire library
appears to be written under great time pressure. The API is often
counter-intuitive and does not provide features that people would
expect, as very similar features are provided. For example, it has
an interface API for relational databases, but it is not possible
to write an application that is agnostic of the specific interface
implementation, as the application always needs to create instances
of specific implementation classes - they forgot to provide central
factory functions.

Regards,
Martin

[Michel Claveau, résurectionné d'outre-bombe inform]

re-Hi !

Python est too late !

Here, I had see a COMPLETE implementation of BrainFuck pour .NET & Mono :

http://bluesorcerer.net/esoteric/bf.html


;o)))

[Mathias Waack]

Tor Iver Wilhelmsen wrote:

3) No multiple inheritance
MI is a crutch.

Misuse of MI is a crutch. And its easy to abuse MI. But thats not a
problem of MI.

4) No serious generic programming support

Apparently coming in 2.0.

Nice argument;)

Mathias

[Ivan Voras]

Peter Hansen wrote:

Marek Baczyński wrote:

Dnia Wed, 28 Jul 2004 19:53:48 -0400, Peter Hansen napisał(a):

As near as I can figure, those who find Python has significant
advantages for many applications over Java and C++ will likely
feel the same way about C#, only more so. Isn't it basically
a highly MS-centric remake of Java, but missing the very
cross-platform nature which has served Java (and Python) best?

Isn't it MS-centricity that serves C#? IMHO it's so popular (relatively)
because MS backs it.

That's exactly what I thought, but clearly the OP thinks
differently or (it seems to me) he wouldn't be asking the question
he asked (or in the way he asked it).

Well, it is certainly a big factor. I watched development of Mono with
interest, and I tried it very soon after it went "release", on FreeBSD.
Now, it only runs on a recent development version of the system, due to
unresolved quirks with pthreads that FreeBSD has, but the parts that do
work, work well. (It was actually a suprise with me, I thought it had
much reason to fail). That success lead me to get to know C# a bit
better, so I got a book and started reading.

I agree very much with posts further down the thread by Derek Thompson
and Martin v. Lowis.

The language itself is much more complex than Python (with which I
didn't get a book and I think I know it pretty well), it certainly
doesn't have Pythons elegance in some fields, like lambda functions, and
I don't think it even has things like generators, but IMO, it's *way*
cleaner than Java. I've done a lot of development with Borland Delphi
(Pascal), so my judgement might be influenced by seeing so much of
things I love and use in D. made it in C# (i think a Delphi architect
was part of the C# team at MS), my favourite being "properties" and
"indexers", (indexers = treating classes/properties as array; something
like overriding [] operator), and "ignoreable" exceptions.

Regarding similarity with Python, i though I saw recent Python versions
also have properties and single-root-class (is this what 'new classes'
are about?). C# (or rather, the class lib) also has modern structures
like dictionaries, stacks, etc.

The only part I'm really dissapointed by is the GUI development. It
seems that while the Windows.Forms API is "standard" and published, many
"real life" .net programs call Win32 API in addition to that, so it gets
complicated. I hadn't had great success with Gtk#. It seems Python has
much advantage here.

Oh, I have to mention speed: I made some simple benchmarks, and the JIT
in .net is fantastic! A simple numeric adder-loop in python (with 1e9
iterations, with xrange...) takes about 30min (hadn't tried psyco yet),
while C# code is on par with compiled C code (about 2 sec.) - it seems
they did a hell of a good job there.


--
What part of "Ph'nglui mglw'nath Cthulhu R'lyeh wgah'nagl fhtagn" don't
you understand?

[Christopher T King]

> Here, I had see a COMPLETE implementation of BrainF*** pour .NET & Mono:

http://bluesorcerer.net/esoteric/bf.html

<shameless plug>
Well, if this is where the thread is going, here you can find a complete
BF implementation for PostScript:

http://users.wpi.edu/~squirrel/postscript/bf.ps
</shameless plug>

;)

[Derek Thomson]

On Thu, 29 Jul 2004 16:02:03 +0100, Alan Kennedy <al****@hotmail.com> wrote:

Tim Bray (XML) is dipping his toe in the
python waters, Steve Vinoski (CORBA) seems tired of the brittleness of
static languages for building distributed object systems, and is
trying his hand with twisted python,

I suspect he'll be disappointed with "Twisted", as I was. I had a
quick look at it, and the support for RPC is primitive, at best.

It's a "round-peg-square-hole" situation given that Twisted is "event
based", but it's pretty hard to build a distributed object system if
you can't call a method on a remote object easily ... still, it may
just be a matter of focus (i.e. the Twisted team haven't really
haven't done much in the area of RPC/distributed objects yet, by the
look of it). It will be interesting to see how it develops over time.

[Elbert Lev]

C# IS a good language and .NET is a very good environment. Recently I
had to write a little program. "one of a kind", "throw away". It took
2.5 hours to finish the proto. Worked fine, but would requere night to
run. Had to rewrite in... C++ or C#. Having the proto in Python, C#
program was written almost as fast as Python's one. The run finishhed
in 1 hour.

Important - Python realities (not exotic) map on C# perfectly.

[John]

"Neal D. Becker" <nd*******@verizon.net> wrote in message news:<ma*************************************@pyth on.org>...

After reading a tutorial on c#, I see immediately that it has all the
features that I disliked in Java.

1) Everything is derived from "Object"
2) Some things have value semantics, some have reference
3) No multiple inheritance

I'm not sure about 2 others:

4) No serious generic programming support
5) Only OO supported:

(This is HelloWorld is C#. Is this actually different than HelloWorld in
java???)

using System;
public class HelloWorld
{
public static void Main()

{
// This is a single line comment

Console.WriteLine("Hello World! From Softsteel Solutions");
}
}

When I saw .NET, I immediatly saw that it addressed the issues that
bothered me most in Java.

1.) No classpath issues.
2.) Built for productivity. Java has almost no helper classes. These
are things that don't REQUIRE to be there but are there for
convenience. Check the recent talk by Bruce Eckel
(http://video.haas.berkeley.edu:24874...kel6-25-04.rm).
I don't think any of his criticism applies for C#.
3.) A sensible, easy to use GUI library (even if it isn't very
portable).
4.) IO doesn't require me look up the manuals each time to figure out
which 3 or so classes I need this time.
5.) Excellent performance (Not just on paper).
6.) Easy deployment.
7.) Absolutely the best web development framework (OK! I may be
getting a bit religious here but I love the component and event driven
model. JFaces as I looked at it was not very mature).
8.) Community that does think that it has to use every single design
pattern in every single library.
9.) An IDE that actually feels simple.
10.) DESIGNED for multiple languages (I admit I rediculed this till
recently saying that all languages needed needed to be like C# to be
supported and it was no better than Java in this. But with IronPython
and F#, it looks a bit promising. But I need them to be integrated
into Visual Studio for me to love them.)
11.) Distributed computing for mere mortals. EJB maybe better designed
than COM+ and more portable. But something must be wrong about it's
design that it scares me away each time.
12.) I hate MVC (OK! It is not Java's fault that every Java programmer
wants it).

I am actually looking forward to IronPython a lot. Has anyone figured
out how to build a .NET assembly out of it? I just looked at it for a
few minutes. I couldn't get UtilLibraryBuilder to work. Maybe it was
just me.

[Valentino Volonghi aka Dialtone]

On Fri, 30 Jul 2004 10:11:13 +1000, Derek Thomson wrote:

I suspect he'll be disappointed with "Twisted", as I was. I had a
quick look at it, and the support for RPC is primitive, at best.

It's a "round-peg-square-hole" situation given that Twisted is "event
based", but it's pretty hard to build a distributed object system if
you can't call a method on a remote object easily ... still, it may
just be a matter of focus (i.e. the Twisted team haven't really
haven't done much in the area of RPC/distributed objects yet, by the
look of it). It will be interesting to see how it develops over time.

Err... What do you mean? Twisted has, at least, 3 different ways of doing
RPC: Perspective Broker, SOAP and XML-RPC.

Perspective Broker is a new RPC protocol which lets you pass objects
remotely and so on.
The other 2 are already well known.

This is a pb server and down here a pb client. How is this
'primitive'? (SOAP and XML-RPC are a lot like these 2 examples below)
====
from twisted.spread import pb
from twisted.internet import reactor

class Echoer(pb.Root):
def remote_echo(self, st):
print 'echoing:', st
return st

if __name__ == '__main__':
reactor.listenTCP(8789, pb.PBServerFactory(Echoer()))
reactor.run()

====
from twisted.spread import pb
from twisted.internet import reactor
from twisted.python import util

factory = pb.PBClientFactory()
reactor.connectTCP("localhost", 8789, factory)
d = factory.getRootObject()
d.addCallback(lambda object: object.callRemote("echo", "hello network"))
d.addCallback(util.println)
d.addCallback(lambda _: reactor.stop())
reactor.run()
====

--
Valentino Volonghi aka Dialtone
Linux User #310274, Proud Gentoo User
Blog: http://vvolonghi.blogspot.com
Home Page: http://xoomer.virgilio.it/dialtone/

[John]

"Neal D. Becker" <nd*******@verizon.net> wrote in message news:<ma*************************************@pyth on.org>...

After reading a tutorial on c#, I see immediately that it has all the
features that I disliked in Java.

1) Everything is derived from "Object"
2) Some things have value semantics, some have reference
3) No multiple inheritance

I'm not sure about 2 others:

4) No serious generic programming support
5) Only OO supported:

(This is HelloWorld is C#. Is this actually different than HelloWorld in
java???)

using System;
public class HelloWorld
{
public static void Main()

{
// This is a single line comment

Console.WriteLine("Hello World! From Softsteel Solutions");
}
}

I just posted a message. But reading the above post again, I note that
Neal was talking about Java, the language. Not Java, the platform. My
comments were mostly on the platform.

[Tor Iver Wilhelmsen]

jo*******@rediffmail.com (John) writes:

1.) No classpath issues.
It *does* have classpath issues - sometimes even greater than Java's -
but most of the time this is hidden from the developer.
3.) A sensible, easy to use GUI library (even if it isn't very
portable).
Swing is sensible and easy to use in my experience.
4.) IO doesn't require me look up the manuals each time to figure out
which 3 or so classes I need this time.
Why not? Because the APIs closer match another language you've used?
If so, coincidence.
5.) Excellent performance (Not just on paper).
Performance should be about the same, since both languages are
compiled to native code on startup.
6.) Easy deployment.
Oh, Microsoft's fabled "xcopy deployment"? How is copying a jar file
harder than compying an EXE plus required DLLs?
7.) Absolutely the best web development framework (OK! I may be
getting a bit religious here but I love the component and event driven
model. JFaces as I looked at it was not very mature).
JavaFaces seems to match the functionality of ASP.Net's CodeBehind
logic, except you're not restricted to an event model; you configure
events yourself in XML files. IDE support for it is coming.
9.) An IDE that actually feels simple.
Which Java IDEs have you tried? And which C# ones?
10.) DESIGNED for multiple languages (I admit I rediculed this till
recently saying that all languages needed needed to be like C# to be
supported and it was no better than Java in this. But with IronPython
and F#, it looks a bit promising. But I need them to be integrated
into Visual Studio for me to love them.)
The only language designed for .Net is and will always be C#. The
other languages are *wrestled* into the CLS strait-jacket, and for
some - like C++ - it does not fit well.
11.) Distributed computing for mere mortals. EJB maybe better designed
than COM+ and more portable. But something must be wrong about it's
design that it scares me away each time.
But EJB is not the be all and end all of Java distributed computing.
If RMI is sufficient, use RMI.
12.) I hate MVC (OK! It is not Java's fault that every Java programmer
wants it).

Why do you hate MVC? Are you addicted to subclassing and code
duplication?

[Elbert Lev]

Mathias Waack <M.*****@gmx.de> wrote in message news:<ep************@valpo.de>...

Tor Iver Wilhelmsen wrote:

4) No serious generic programming support

Apparently coming in 2.0.

Nice argument;)

What is wrong with this argument. Java evolved for more then 10 years
(and still is). This group is dedicated to an evolving language -
Python. Why not to allow C# to evolve too.

[Martin v. Löwis]

Elbert Lev wrote:

4) No serious generic programming support

Apparently coming in 2.0.

Nice argument;)

What is wrong with this argument. Java evolved for more then 10 years
(and still is). This group is dedicated to an evolving language -
Python. Why not to allow C# to evolve too.

Sure. And ten years from now, the issue of C# not providing generic
programming might not be an issue anymore. However, this is not
relevant for people who use C# today - they just can't use generics;
that future versions may provide it still means they can't use it
today. So if this is a flaw, it is a flaw today. Saying that people
want to remove the flaw still makes it a flaw.

Specifically talking about Microsoft, "a future release may" is makes
a particulary bogus argument. There have been many examples where the
future release did not actually provide the feature that Microsoft said
it would provide, and even more examples where the future release might
be delayed so much that the release was irrelevant for the original
problem (which was then solved long ago, by different means).

Regards,
Martin

[Duncan Booth]

"Martin v. Löwis" <ma****@v.loewis.de> wrote in
news:41**************@v.loewis.de:

What is wrong with this argument. Java evolved for more then 10 years
(and still is). This group is dedicated to an evolving language -
Python. Why not to allow C# to evolve too.

Sure. And ten years from now, the issue of C# not providing generic
programming might not be an issue anymore. However, this is not
relevant for people who use C# today - they just can't use generics;
that future versions may provide it still means they can't use it
today. So if this is a flaw, it is a flaw today. Saying that people
want to remove the flaw still makes it a flaw.

Whilst what you say is true in general, C# containing generics is available
today (although still in beta). See http://lab.msdn.microsoft.com/vs2005/

BTW, elsewhere in this thread someone said that C++ doesn't fit well into
..Net framework so it is worth mentioning that vs2005 also includes
completely revamped support for C++. Naturally this is incompatible with
their earlier attempt, but it really is much improved.

[Martin v. Löwis]

Duncan Booth wrote:

Whilst what you say is true in general, C# containing generics is available
today (although still in beta). See http://lab.msdn.microsoft.com/vs2005/

Yes, patches implementing that have been floating around (for Rotor) for
many several now, and they are available for mono as well. Yet, I still
have to see an actual release of .NET 2.0, to provide the feature. It
appears that this might ship along with Visual Studio Whidbey (2005 or
later) or Windows Longhorn (2007 or later).

These days, Microsoft follows the principle "publish early, publish
often", giving the impression that a release is imminent. I haven't
read the license, but I doubt it would allow me to ship applications
for .NET 2.0, let alone shipping the .NET 2.0 redistributables.

Regards,
Martin

[Derek Thomson]

On Fri, 30 Jul 2004 08:50:16 +0200, Valentino Volonghi aka Dialtone
<di**********************@virgilio.it> wrote:

On Fri, 30 Jul 2004 10:11:13 +1000, Derek Thomson wrote:

I suspect he'll be disappointed with "Twisted", as I was. I had a
quick look at it, and the support for RPC is primitive, at best.

It's a "round-peg-square-hole" situation given that Twisted is "event
based", but it's pretty hard to build a distributed object system if
you can't call a method on a remote object easily ... still, it may
just be a matter of focus (i.e. the Twisted team haven't really
haven't done much in the area of RPC/distributed objects yet, by the
look of it). It will be interesting to see how it develops over time.
Err... What do you mean? Twisted has, at least, 3 different ways of doing
RPC: Perspective Broker, SOAP and XML-RPC.

Yeah, I know - I said "easily" :) It's basically the client side API I
have a problem with:

====
from twisted.spread import pb
from twisted.internet import reactor
from twisted.python import util

factory = pb.PBClientFactory()
reactor.connectTCP("localhost", 8789, factory)
d = factory.getRootObject()
d.addCallback(lambda object: object.callRemote("echo", "hello network"))
d.addCallback(util.println)
d.addCallback(lambda _: reactor.stop())
reactor.run()
====

So, why can't it just be basically:

object.echo("hello network")

.... as it is in CORBA and (other) XML-RPC and SOAP toolkits I've used.

I also have a problem with the insistence on the use of asynchronous
callbacks. In order to use the result of the RPC call later in the
main flow of my code, I have to somehow block in the main thread for
the the result to be returned from the server via the callback - this
is something that can be done for me, and is handled simply and
transparently in other RPC toolkits/mechanisms I've used.

I'll try to characterize this with a simple example. How would I write
something like this, where I have three distributed objects:

i = an_object.get_value()
j = another_object.get_value()
k = yet_another_object.combine(i, j)

.... and now finally use "k" in my code?

I could be missing something, but isn't that going to turn into a mess
of dependant callbacks in Twisted? Aren't I going to have to write a
whole lot of code that blocks until the results come back? I don't
mean this as a challenge or a judgement anything, I'd honestly like to
know - I would like to look further into Twisted but was pretty much
put off by this issue right from the start.

Regards,
Derek.

[Sam Holden]

On Sat, 31 Jul 2004 13:37:35 +1000,
Derek Thomson <de***********@gmail.com> wrote:

On Fri, 30 Jul 2004 08:50:16 +0200, Valentino Volonghi aka Dialtone
<di**********************@virgilio.it> wrote:

On Fri, 30 Jul 2004 10:11:13 +1000, Derek Thomson wrote:

Err... What do you mean? Twisted has, at least, 3 different ways of doing
RPC: Perspective Broker, SOAP and XML-RPC.
Yeah, I know - I said "easily" :) It's basically the client side API I
have a problem with:

====
from twisted.spread import pb
from twisted.internet import reactor
from twisted.python import util

factory = pb.PBClientFactory()
reactor.connectTCP("localhost", 8789, factory)
d = factory.getRootObject()
d.addCallback(lambda object: object.callRemote("echo", "hello network"))
d.addCallback(util.println)
d.addCallback(lambda _: reactor.stop())
reactor.run()
====

So, why can't it just be basically:

object.echo("hello network")

... as it is in CORBA and (other) XML-RPC and SOAP toolkits I've used.

I also have a problem with the insistence on the use of asynchronous
callbacks. In order to use the result of the RPC call later in the
main flow of my code, I have to somehow block in the main thread for
the the result to be returned from the server via the callback - this
is something that can be done for me, and is handled simply and
transparently in other RPC toolkits/mechanisms I've used.

Twisted is asynchronous so obviously it makes such a demand. You don't
have a "main thread" to block anyway - twisted calls your code for
you...

Obviously if you don't like that style of programming you won't like
twisted.

I'll try to characterize this with a simple example. How would I write
something like this, where I have three distributed objects:

i = an_object.get_value()
j = another_object.get_value()
k = yet_another_object.combine(i, j)
So that doesn't call another_object.get_value() until an_object.get_value()
completes?

That's be nasty for high latency (due to network delays or lots of server
computation or whatever) RPC.

... and now finally use "k" in my code?

I could be missing something, but isn't that going to turn into a mess
of dependant callbacks in Twisted? Aren't I going to have to write a
whole lot of code that blocks until the results come back? I don't
mean this as a challenge or a judgement anything, I'd honestly like to
know - I would like to look further into Twisted but was pretty much
put off by this issue right from the start.

I must admit I haven't been using twisted for long, and I haven't used RPC
at all, but my first crack at it would be (based on the original example):

The server:
===
from twisted.spread import pb
from twisted.internet import reactor

class Echoer(pb.Root):
def remote_echo(self, st):
print 'echoing:', st
return st

def remote_reverse(self, st):
print 'reversing:', st
l = list(st)
l.reverse()
return ''.join(l)

def remote_concat(self, a, b):
print 'concating:', a, 'and', b
return a+b

if __name__ == '__main__':
reactor.listenTCP(8789, pb.PBServerFactory(Echoer()))
reactor.run()
===

The client:
===
from twisted.spread import pb
from twisted.internet import reactor
from twisted.python import util
from twisted.internet import defer

def do_stuff(obj):
d1 = obj.callRemote("echo", "abc")
d2 = obj.callRemote("reverse", "abc")
dl = defer.DeferredList([d1, d2])
dl.addCallback(lambda r: obj.callRemote("concat", r[0][1], r[1][1]))
dl.addCallback(util.println)
dl.addCallback(lambda _: reactor.stop())

factory = pb.PBClientFactory()
reactor.connectTCP("localhost", 8789, factory)
d = factory.getRootObject()
d.addCallback(do_stuff)
reactor.run()
===

That's missing error checking and all that stuff, but it seems simple
enough.

Replace util.println with a callback that does the 'and now finally use
"k" in my code' stuff.

I also only used the one remote object, but that's easy to change.

[Tor Iver Wilhelmsen]

jo*******@rediffmail.com (John) writes:

OK! I am unaware of any. Can you point me to some.
Well, the one I "crashed" into was when I (by mistake) had compiled
Microsoft's free ASP.Net container (Cassini) using version 1.0 of the
framework, while my ASP.Net application was compiled using version 1.1
of the framework. The result was that the container complained that it
could not find the superclass for my page, since the 1.0 version of
System.Web.HttpApplication is *not* the 1.1 version of
System.Web.HttpApplication. It doid not even try to use it.

In Java, I *might* later have received a runtime exception about a
missing method, if I actually used a method that was too "new".

(The solution to the Cassini problem was to manually write an
application .config XML file that told it to use the 1.1 framework.
This config file is also where you define any dependencies to
particular versions of libraries; by default an application will use
the newest available.)
Yes! Why do I have to list every jar file I use for the application in
the classpath? Why can't I just drop them in the same folder with the
app and expect the JVM to find them.
You can, if the jars are included in your "main jar"'s manifest's
Class-Path value, e.g.

Main-Class: some.Application
Class-Path: library.jar stuff.jar

Setting this up is, as in the case of .Net, a task for your IDE.
Isn't that intuitive? Practically every VM language I know does
that. Current folder had to be listed in explicitly in the current
path.
For safety reasons: These are Unix people. You simply don't trust the
current directory.
Is that intuitive? Every other language behaves the other way.
Er, "languages" don't behave in that way, executables do. Executables
look in your path environment variable, which the user need to keep up
to date; the Win2k family has moved the setting of that to a
relatively obscure location in the system properties dialog - not very
friendly.

..Net applications look in the "assembly cache", which also needs to be
kept "up to date". You can override dependencies using the "user
friendly" syntax described in

http://msdn.microsoft.com/library/de...orkVersion.asp
You are a Java developer and probably have used these IDE's over an
extended period of time to no longer see the complexities within.
I've used JBuilder and JDeveloper almost exclusively; I never could
get my head around the "project-less" directory-focused and slow
NetBeans.
To quote an example, we teach Java here. I was discouraged to
introduce Eclipse (which is much simpler than the other Java IDEs and
I loved it immediately after coming across it for the first time) to
the students because it overwhelmed them. On the other hand, I would
not even want to introduce C# without Visual Studio.
Because it hides the .Net complexities from the developer. Is that a
good thing?
They seemed to compile Quake 2 fine.

How much of it ended up as unmanaged code? An application that runs
outside of the managed container is not a .Net application.

[Tor Iver Wilhelmsen]

Michael Ekstrand <py****@elehack.net> writes:

Why do you say this?
Because many languages are made without it (Java, C#, Smalltalk), a
major language having it (C++) implements it in a way that makes a
developer need to be super-careful when using it, and any problem that
can be solved using MI can be solved without using it.
A while ago, I was working with an object model in which there was
no effective way to represent the necessary data without multiple
inheritance (which made things really interesting when I was
considering porting it to Java).

Java has indirect support for MI using nested classes.

[Lawrence Oluyede]

In data 31 Jul 2004 11:29:10 +0200, Tor Iver Wilhelmsen ha scritto:

Java has indirect support for MI using nested classes.

Nesting classes is an unneeded complication, and AFAIK is not pure MI. I
think that the only "bare MI support" that Java does have are MI of
interfaces...

bye!

--
Lawrence (l dot oluyede at virgilio dot it)
"In IE we trust"

[Tor Iver Wilhelmsen]

Lawrence Oluyede <ra***@dot.com> writes:

Nesting classes is an unneeded complication, and AFAIK is not pure MI. I
think that the only "bare MI support" that Java does have are MI of
interfaces...

There is nothing pure about MI. But that's a religious dicussion.
Python handles it better than C++ at least.

[Dan Bishop]

Tor Iver Wilhelmsen <to*****************@broadpark.no> wrote in message news:<uv***********@broadpark.no>...

Lawrence Oluyede <ra***@dot.com> writes:

Nesting classes is an unneeded complication, and AFAIK is not pure MI. I
think that the only "bare MI support" that Java does have are MI of
interfaces...

There is nothing pure about MI. But that's a religious dicussion.
Python handles it better than C++ at least.

And ironically, there's less of a need for MI (and inheritance in
general) in Python, because it's dynamically typed.

I don't think I've ever used MI in Python.

[Edward Diener]

Tor Iver Wilhelmsen wrote:

Lawrence Oluyede <ra***@dot.com> writes:

Nesting classes is an unneeded complication, and AFAIK is not pure
MI. I think that the only "bare MI support" that Java does have are
MI of interfaces...

There is nothing pure about MI. But that's a religious dicussion.
Python handles it better than C++ at least.

Why do you say that ? In other words, what in Python's implementation of MI
is superior to C++'s implementation of MI ?

[Martin v. Löwis]

Edward Diener wrote:

Why do you say that ? In other words, what in Python's implementation of MI
is superior to C++'s implementation of MI ?

In Python, MI is easier to understand than in C++. The state definition
for an object is simpler, as there is no need for virtual-vs-non-virtual
inheritance. Also, there are no casting issues in Python that cause
common errors in C++ (because in MI, casting can change the
representation of the address of an object).

Regards,
Martin

[Lawrence Oluyede]

In data 31 Jul 2004 17:30:23 -0700, Dan Bishop ha scritto:

And ironically, there's less of a need for MI (and inheritance in
general) in Python, because it's dynamically typed.

I don't think I've ever used MI in Python.

Yeah, me too, I prefer the mixin approach, anyway, if you want to take a
look at a framework (with a wonderful API IMHO) that massively uses MI
watch Soya3D sources: http://home.gna.org/oomadness/en/soya/

--
Lawrence (l dot oluyede at virgilio dot it)
"In IE we trust"