xharbour and dotnet

La semana pasada participé en un debate en la lista de noticias de xharbour. El tema inicial era un anuncio sobre un lenguaje xbase para la plataforma .Net pero luego se volvió bastante interesante, y trata sobre el porqué de mi interés en mono.

Massimo Belgrano: Seem that vo is near to the dotnet version http://www.vulcandotnet.com/. Any plan for xharbour dotnet version also for commercial distribution?

Marek Paliwoda: It seems they have also a Linux version running under Mono … If that’s true it is very likely that Vo will become a «killer app» for all other xbase products 🙂 .

I do not know about any attempts or plans to make xh for NET at this moment. I am affraid nobody is interested in such a version currently. Maybe something will change in a future …

Till that moment, all xbase developers interested in NET, can choose CuleNET or wait for an upcoming Vulcan.NET 🙂 .

José Luis Sánchez: I apologize.

VO a ‘killer app’ ?

I think that VO was the app who killed the best programming language developed ever for personal computers. And we are lucky that [x]Harbour guy’s returned it to live.

Marek Paliwoda: Not VO – Vulcan.NET

> I think that VO was the app who killed the best programming language developed ever for personal computers.

Maybe – if you are talking about *old* VO. But it is an over-simplification IMO. Look at VO community – seems to be bigger than xh community. How can you explain this taking info account that «VO killed the best language» ?

> And we are lucky that [x]Harbour guy’s returned it to live.
Undoubtly.

However look around – how many *new* developers are deciding to enter the xbase world, either with xharbour or other Clipper like products ? My observations are – very, very few. xbase becames niche – smaler and smaler. And xh did not change much in this trend. Maybe Vulcan.NET or CuleNET (or xh.NET) will ?

Tim Stone: Perhaps … but .NET products are still struggling. I’ve been involved in testing several and performance is very slow. I know a lot of work is going into .NET development, but I’m not sure how many «end products» are being embraced at this time.

I can see it more for document sharing and processing, but true database work relies on fast performance.

Marek Paliwoda: You may or may not believe, but here almost *all* new products from firms I have contacts with, are NET based. I doubt elsewhere is differently.

> I can see it more for document sharing and processing, but true database work relies on fast performance.

This is a very personal point of view. Mine is that true database work depends on a good database engine and a very good database project. NET helps building modern and rich user interface. All the rest (well, almost all) is done on a backend (database engine).

Thanks for sharing your opinion.

José Luis Sánchez: I don’t know which community is bigger, but I’m sure that if CA didn’t buy Nantucket now we would have a big community.

I really think that .Net is comming a mature environment, and with mono you can do development for Windows and Linux. In fact, I’m beginning with .Net framework and my goal is develop with mono in Linux in a couple of years. But I will learn C# for this, once I decided to jump to mono I will play the game with their own cards.

Marek Paliwoda: I went this route years ago. It was an amazing journey and I never regreted. I had to learn *lots* of things about NET : CLR, ASP.NET, assemblies, code security etc. One of the things I’ve learned is that *it doesn’t really matter* what language you choose to write NET apps. Language in NET is mostly «a sugar». That’s NET which gives you the power – not the language. You choose the language you preffer to utilise NET power. That’s why CuleNET and Vulcan.NET are important IMO. They open NET for us using our prefferd xbase syntax. While this does not guarantee that new programmers will choose xbase way to play with NET, it certainly opens new posibilites for those used to «old» Clipper, VO, Xbase++, etc. Xh gave us the hope for a very short amout of time unfortunately, due to amazingly quick technology progress.

The fact is that «old xbase world» is die-ing. And this process happens quicker and quicker. Will CuleNET and Vulcan.NET change this ? I don’t know … but I hope yes.

I wish I am wrong in my opinions.

Thanks for taking your time in this discussion.

José Luis Sánchez: I don’t think xbase world is die-ing. I develop shareware and for me xHB is the perfect lenguage, but I want to learn a new framework that give me new perspectives about my profession. I’ve decided learning mono but I will not leave xHB. I want to try for myself things like NAnt, NUnit that I can’t use with xHB.

Ron Pinkas: Can you please explain, what in your opinion is standing in the way of the xHarbour developers, prohibiting the support any new technologies?

IOW, what makes it so much easier, for the developers of any other development product, to support that «quick technology progress», to the point that xHarbour will simply not able to compete, beyond a «very short amount of time»?

I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Marek Paliwoda: Complete lack of interes from those who would be able to keep xh «up to date» due to their enough knowledge and desire. Sorry Ron, xh is descendant of hb. Hb had around 30 developers (AFAIK), xh has around 50 developers. How many of them *really* develop xh ? How many of them can devote all their time for xh ? How many of them are familiar with
new technologies and with xh internals (I am talking about *deep* knowledge here) ?

Before you will try to answer, please consider the fact that lately you were looking for voluntiers to take care of orphan xh modules like regex, hashes, network funcs, etc … without success so far 🙁 (hope this will change).

It seems to me those from other products had found talented individuals from which they created a development teams which work full time on their products. This is different than in xh.

Long ago I was conviced that OpenSource model of development is better than comercial. Now I think quite the oposite way. It is much easier for comercial companies to find talented individuals. This is a simple matter of economy 🙂

> I for one, see xHarbour as an amazingly powerful, modern, open, development tool, which has a track record, showing how quickly it can embrace and support, new technologies, platforms, etc..

Yeah … , like COM/OLE for example … This technology is more than 10 years old. I couldn’t call xh support for it even «basic» 🙂 . No type information, no support (or wrong support) for some COM types (like SAFEARRAY’s), no support for parameters by ref, no support for events/callbacks, no activex support, no support for DCOM, etc.

Sure, You couldn’t write anything other than that. Besides everything, you sell xh 🙂 .

Ron Pinkas: Marek,

People may be slow to take responsability, yet they are more than happy to contribute, as you well know. Additionaly, primary contributions seem to come from NEW Individuals, as they step forward to take advantage for new technologies that THEY NEED. This is how most great contributions arrived to xHarbour, and why we have some 50 developers.

Maybe you should ask yourself WHY is it, that I sell xHarbour, why are you here, and why are so many other tremendously creative developers [of
«main-stream» languages] here?

Marek: I mentioned about COM/OLE not because it’s something new (in fact I wrote it’s an old technology), but because having a working COM/OLE support would allow as at least using NET components thru NET/COM interoperability. Much like VFP and VO do. Sure it would be some kind of «hack» but better than nothing 🙂 – I am not sure if you realise that having xh for NET will reguire to rewrite xh almost from *scratch* if you want to have pure NET solution … Taking into acount that even an old technology is not well supported in xh I think it’s quite resonable to assume that the new one will have similar problems. You may or may not agree with this. Please note I am not against xh – I am still going to play with it 🙂 . But this does not mean I do not see xh problems (IMO),
and I am looking at other options also (CuleNET, Vulcan.NET).

El hilo completo se puede seguir en news://news.harbour.com

3 comentarios en «xharbour and dotnet»

  1. Es paradójico, no?
    He visto muchas veces estas críticas sobre que xHarbour supuestamente no tiene planes para desarrollar versiones de .NET

    Pero los que critican, tampoco hacen nada al respecto.
    No hay propuestas, ni sugerencias. Sólo hacen comparaciones.

    Qué fácil que es criticar sin hacer, no?

    Si están tán a gusto con esas tecnologías que salgan corriendo y las usen.
    Y si quieren que xHarbour migre o tenga una opción de migración, entonces que construyan.
    La crítica no construye.

    Además, las críticas se hacen sin conocimiento real de lo que es .NET, solo con el conocimiento de que muchos están desarrollando en .NET y de que es lindo, portable, etc.

    Y los datos necesarios para desarrollar ?
    El análisis del código IL ?
    El análisis de portabilidad ?
    Analizaron las características de estos lenguajes portados y sus limitaciones ?
    Algunos de estos críticos pensaron en como portar las macros ?

    «Ah, no, eso es tarea de los desarrolladores, yo solo hago criticas «constructivas» para que se pongan a analizar»

    La mayoría de los críticos piensan como usuarios, no como desarrolladores, por eso critican.

  2. Walter:

    Los post no se publican con ánimo de ofender a nadie. Nunca tomes una palabra mia como una crítica, por favor.

    Yo estoy muy contento con xHarbour, pero el mundo no se acaba aquí. Hay muchos otros entornos y creo que es bueno aprender otras cosas para poder al menos comparar con un cierto fundamento. Es innegable que hay un continuo desarrollo de este entorno, es muy difícil aguantar el ritmo a una empresa como Microsoft.

    El tema de los desarrollos OpenSource es algo muy complejo. Hace poco en un blog que te recomiendo – http://najaraba.blogspot.com/ – el autor se planteaba cuantas empresas *hacen* software libre en España. La conclusión que sacaba era que muchas lo usaban pero pocas realizaban los desarrollos. ¿ Paradójico no ?

    Saludos,

  3. Jose Luis:

    De ninguna manera me refería a ti.

    Y tampoco solamente al planteo de un xHarbour.NET

    No es la primera vez que se plantea el tema de .NET y otros temas relacionados con tecnologías de «moda». (Quizas no sea la palabra adecuada pero no se me ocurre otra)

    El asunto es que todas estas críticas apuntan a que el equipo de desarrollo *debe* responder.

    Pero parecen olvidarse que:
    1 – Dedicamos parte de nuestro tiempo para tener un mejor compilador que nos sirva a nosotros y al resto de los que lo quieran usar.

    2 – Si no conocemos o no tenemos tiempo para estudiar y planificar como debería ser xHarbour.NET, por más críticas que haya, no vamos a ir a ninguna parte.

    3 – Y lo que más me desagrada es de gente que participa del equipo de desarrollo, pero a la hora de criticar lo hace en forma pública.
    Y no solo eso, sino que además hacen críticas sin un conocimiento completo del estado actual de xHarbour y de como debería estar para ser .NET compatible.

    Como ya dije en mi primer comentario, en toda la discusión solo se ven las críticas y las comparaciones de productos por su nombre, pero no hay análisis de sus características.

    No tuve tiempo de ver Vulcan.NET, pero si he visto Cule.NET y está muy lejos de ser compatible con xHarbour.
    Probablemente no se hayan pasado por esas diferencias.
    Pero tampoco se han preguntado el por qué Cule.NET no implementa cosas que estan implementadas en xHarbour ?
    o por qué otros lenguajes que han pasado a .NET han tenido que recortar sus características para amoldarse al esquema .NET ?

    La conclusión que se debe tomar de mis palabras, es que para poder tener un xHarbour.NET hay que estudiar mucho, muchisimo a .NET y su entorno con cosas como C++ Administrado o Managed C++.

Los comentarios están cerrados.