Re: [vos-d] Swig

2006-03-13 Thread George Birbilis

Plus the GNU guys have been building a C# compiler 
that compiles to native code and targets native libraries (instead of a .NET [or 
compatible] runtime). So one could use it instead of C++ I suppose on 

---George Birbilis [EMAIL PROTECTED]Microsoft MVP J# 

  That it costs anything is a common misconception:
  The Microsoft C# compiler comes for free with Windows.
  You can download the Visual Studio 2005 Express Editions for free for a 
  You can download other integrated development enviroments for free (such 
  as SharpDevelop)
  You canbuild C# in Mono for free, which also runs on Linux which is 
  a free OS.
  All the MSDN documentation is available for free online.
  So altogether, it is highly possible to spend no money and build C# 
  On 3/12/06, sconzey 

The problem is that as far as I know, C# isn't 
anywhere near as portable as python, nor is it anywhere near as open. There 
are many free python development applications, whereas to write C# requires 
£300 worth of software. My vote's cast for python.

On 3/12/06, Hugh Perkins 

  After playing around a little with C#, I have to agree with Neil: C# 
  Just to throw some salt in the wounds of the Python discussions, I 
  cant help thinking that C# has all the advantages of both Python (run from 
  source, easy to read) and C++ (strong typing, runs quickly).
  Btw, OSMP is now available in a C# version ;-)
  On 9/2/05, Neil 

Yep, not had much practise with managed C++ as I'm lazy and C# is so much easier (!), but I guessmanaged C++ 
could be the way to go for integrating with VOS as it can fully utilise 
the C++ classes. 

Still there'd be work required to make the API more ".net 
___vos-d mailing 

QOTD:"Violence is the last resort of the 
Isaac Asimov GPG Public Key: 
mailing listvos-d@interreality.org

  ___vos-d mailing 
vos-d mailing list

[vos-d] Re: [OFF] typing

2006-03-13 Thread Lalo Martins
And so says Peter Amstutz on 14/03/06 14:23...
 That said, there's probably a crossing-over point, where projects
 below some size are better served with a dynamic type system, and
 projects above that size are better server with a static type system.
 The point could also be made that certain dynamically typed languages
 are more powerful (they can acomplish more per line of code) which
 raises the bar.

That is IMO a common misconception from people that don't have a lot of
experience with dynamic typing.  In my experience, static typing is
suitable for *medium* projects, if at all; the larger the project, the
more you want dynamic typing, because it's easier to improve, debug, and
read (large projects have higher rotativity of developers, so being able
to quickly understand the codebase is a major bonus).

As I said before in this thread, I can't think of a project that would
be done better with static typing, except for low-level tasks that you'd
probably rather do in C or assembler.

 So while you can do dynamic type checking in a mostly static
 language, typically you can't do static type checking in a dynamic
 langauge.  In the end this seems less powerful to me.

Not really... you can *emulate* dynamic typing on a more static language
like C++, but you only get dynamic typing between subclasses of a given
root point (RefCounted in the case of VOS, IIRC).  In fact, vRef is one
of the best implementations of dynamic typing for static languages I
remember seeing.

But even that much would be just impossible in C.  You'd have to mess
around with defining your own type system.  It's impossible to
meaningfully find the type of the thing that was passed in one of your
arguments, for example.

On the other hand, it's equally easy to emulate stronger checking on
dynamic languages.  It's just bad practice ;-)

   Lalo Martins
  So many of our dreams at first seem impossible,
   then they seem improbable, and then, when we
   summon the will, they soon become inevitable.
GNU: never give up freedom

vos-d mailing list

Re: [vos-d] Re: [OFF] typing

2006-03-13 Thread Hugh Perkins
On 3/14/06, Lalo Martins [EMAIL PROTECTED] wrote:
And you can constrain even that using slots.If you're interested,contact me in private :-) otherwise, just record the fact that it's
possible.(A class with slots makes all attribute assignments failunless the attribute name is in the slots list.)

Hmmm, that does sound like it resolves this issue. Perhaps it's this simple?

I guess there is one other thing I like about C# compared with using Python, which is that once you've compiled it you know you're not going to wait for the application to load, start trying some command, and Boom! you mistyped a variable name, and the program dies... Is there some way to force Python to compile everything right at the start?

vos-d mailing list