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.

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

entrevista con Roberto López

Hace unas semanas se produjo un gran revuelo con el anuncio por parte de Roberto López de que MiniGUI pasaba de tener una licencia GPL a ser freeware, aunque posteriormente hubo una rectificación dejando de nuevo la licencia como GPL pero con la advertencia de su creador de que no aceptaría colaboraciones. Este hecho produjo un cierto revuelo, llegando el tema a ser barrapunteado.

Ante esto decidí ponerme en contacto con Roberto, quien amablemente respondió a mis preguntas.

La primera pregunta es obvia: ¿ que ha pasado con MiniGUI ? ¿ Porqué el cambio de licencia GPL a Freeware y vuelta atrás a GPL ?

Es lo que he explicado en dos comunicaciones a través de mi sitio el 16 y 23 de Julio.

En pocas palabras, lo que sucedió, es que algunos usuarios muy cercanos al proyecto (moderadores del foro de discusión en Inglés) decidieron publicar una versión alterna de MiniGUI, conteniendo contribuciones de código que habían sido rechazadas por diversos motivos. Los más notorios fueron, incapacidad o falta de interés de sus autores para solucionar problemas en su código, no preservar la compatibilidad con versiones anteriores de sus propias contribuciones, no respetar reglas básicas que permitan mantener la consistencia con el diseño general de la librería, etc.

La primera publicación de esta versión alternativa llevó la denominación 107, presentándose como una continuación de mi trabajo (mi última publicación hasta ese momento había sido la 106a).

Cuando tomé conocimiento de esto, supe, que como autor de la librería, tenía el derecho y el deber, de proteger mi trabajo y a los usuarios que confiaron en él, de acciones de este tipo.

Mi primera iniciativa fue la de publicar la librería (a partir de la versión 2.0) como Freeware, lo cual protegería el código de modificaciones inadecuadas, manteniéndola libremente disponible y gratuita.

Una parte importante de los usuarios, consideró que la no disponibilidad del código fuente, podría llevarlos a tomar la decisión de no continuar usando MiniGUI a partir de la versión 2.0.

Los motivos que expusieron, fueron, en algunos casos muy atendibles, por lo cual decidí tomarme un tiempo para considerarlos.

Finalmente, decidí volver a publicar la versión 2.0, ahora, de la misma forma que siempre (GPL+’Harbour Exception’), pero sin aceptar nuevas contribuciones de código.

En un mensaje reciente en tu página web dices “dejaré de aceptar nuevas contribuciones de código en todas sus formas”. ¿ Has tenido problemas con las contribuciones de código ? ¿ No crees que de esta manera vas a reducir tu comunidad de usuarios ?

La primera parte de la pregunta la he respondido en el punto anterior.

En cuanto a los usuarios, si algo he aprendido en estos años, es que no es posible tomar decisiones que satisfagan a todos.

Algunos considerarán que mi punto de vista es el más acertado y continuarán usando mi versión de MiniGUI, otros creerán que alguna otra alternativa les es más conveniente y ya no contaré con ellos como usuarios. No está mal que sea así y no estoy preocupado por ello.

En la versión 2.0 incluyes en el paquete Harbour y el compilador MingW. ¿ Puedes explicarnos porque Harbour y no xHarbour y el motivo del cambio de compilador C ?

En cuanto a Harbour, cuando el proyecto se dividió, me pareció más razonable la posición de quienes opinaban que debían concentrarse los esfuerzos en completar el trabajo y hacerlo lo más estable y confiable que fuera posible, en lugar de extenderlo, cosa que debía hacerse en el futuro, eventualmente, una vez finalizada la primera versión.

Esta es solo una opinión de usuario y no pretendo influenciar ni molestar a nadie con ella.

Respecto del compilador de C, hace algún tiempo, un usuario de las primeras épocas de MiniGUI (Lorenzo Fiorini) me llamó la atención sobre la licencia de BCC (que hasta ese momento yo creí completamente gratuito).

No soy un especialista en licencias, pero, es bastante claro que BCC tiene serias restricciones en cuanto al uso que puede hacerse del compilador y de los ejecutables generados con él, lo cual es claramente contrario al espíritu de Harbour y al de MiniGUI.

Desde entonces, MingW, surgió como la alternativa ideal, ya que puede distribuirse libremente y los ejecutables generados con él no están sujetos a restricción alguna.

Yo realmente soy un profano en el uso de MiniGUI, ya que he usado Fivewin desde casi sus inicios. He probado MiniGUI y me ha sorprendido la facilidad de
su sintaxis y que está todo perfectamente ensamblado para comenzar a programar en 1 minuto. ¿ Que ofrece MiniGUI a gente como yo ? ¿ Crees que MiniGUI puede competir con los GUI visuales de última generación como Xailer o VXH ?

MiniGUI comenzó como un experimento en Diciembre de 2001, cuando la
crisis aquí, me dejo con mucho tiempo libre que decidí usar para iniciarme en el uso de la interfase Harbour-C.

Nunca fue pensado como un producto que pudiera competir con algún otro.

Yo solo quería una herramienta, que tal como el Clipper original, me permitiera, como programador, concentrarme en el problema a resolver y no en las complejidades del lenguaje utilizado para resolverlo.

Eso es todo lo que MiniGUI ofrece.

Muchas gracias Roberto, y mucha suerte en esta nueva etapa de MiniGUI.

and the winner is…

Después de una semana de vacaciones he vuelto y he visto la relación de nombres propuestos para el programa. Esperaba contestación de alguno de los incondicionales del blog y algo más, como así ha sido. Sobre el nombre, después de leer las propuestas creo que me quedo con la mía, pero vamos a repasar los nombres propuestos:

Sergio propone alejandría. El nombre me gusta, pero lo veo poco trabajado, es un nombre muy a bote pronto.

Lo mismo digo de Biblios propuesto por Antonio Almaraz.

Jepnov propone DocWher … no me gustan los nombres en inglés para los programas. Lo siento.

Memofe propone Musaeum … a mi los nombre en latín me pierden, pero no lo veo fácil de recordar. Agradezco mucho la explicación sobre las bibliotecas, me fascina la gente que sabe Historia.

Pepe propone DocBlog… no me gusta. Inglés y no recordable. Luego propone DocFinder – que no es malo – y PathFinder. DocFinder es bueno, pero me gustan los nombres en castellano.

Juanjo se deja llevar por la moda. Docu.men.to no es malo, pero no es original.

José Alberto propone varios nombres interesantes. Sobre Ptolomeo, Calímaco e Hipatia… pues lo mismo que con Musaeum. Le pones un nombre de estos al programa y acaban llamándole ‘el programa ese’ porque no se acuerdan del nombre. Los nombres en inglés… sorry. Los otros dos, pues no es una biblioteca lo que propongo catalogar, sino una hemeroteca.

El nombre de Ycaña… uffffff. No comments, que luego me dicen que hago amigos en todas partes.

Así las cosas veo difícil un ganador, por lo que opto a dejar el premio desierto. Agradezco a todos los participantes vuestra colaboración y os he enviado la última beta del programa. Esta beta es operativa y no tiene restricciones, aunque le falta todavía por terminar todo el tema de listados.

A todos esto el nombre elegido para el programa – un gestor personal de documentos – es:


El nombre es corto, fácil de recordar y relacionado con la materia que maneja el programa. ¿ Os gusta ?