ADS vs PG

[SlavkoDam]

(Our) Customer nowadays are looking for highly scalable, multi-platform, safe and easy-to-use applications. Integration and scalability are demanded, it must be device-independent and good looking. Data driven, excellent looking, fast and reliable.

Great for your customers if they are so deep in IT knowledge (what I doubt), but its not for all customers in the world. Besides, you can do all the above goals you mentioned, with Xbase++ and add-on tools in Xbase++, using only one technology: Xbase++. What is the most important for the customers is the end result. If you like you can integrate other technologies into Xbase++, I believe you read Otto's work with PHP, what I implement too. As I recall, you are also against FiveWin and WinDev, because you don't want to start from scratch when you have achieved so much in Xbase++. And why would you? You already do the great work in the great way in Xbase++.

Anyway, Xbase++ is only one option amongst the many others, its up to you what you will use, not on the customers. When you get sick and go to a doctor, the doctor will determine your therapy, not you.

[Tom]

What I said is true for > 70 percent of the customers in the german healthcare business. I believe it's almost similar in other businesses and all over the world (except Northern Korea).

What is the most important for the customers is the end result.

No. This is simply not true. Applications must be future-safe and some kind of future-proof. They must be state of the art on the technology- and security-side. They must have a perspective. Large investments are not made only with an eye on the next few years. And the companies and their IT people want to know how and with what it is done. In some businesses, it is necessary to get security certificates for the application. If you come with 32-bit-stuff (!) done in a language nobody knows, you're out.

It is not only the result. That was in the 90s, maybe in the early days of our century. Times have changed.

If you work for small, very pragmatic, one-generation companies, you still may find people thinking the way you mentioned, but the rest of the world is moving.

[SlavkoDam]

German healthcare business is not the only one in the world, and certainly not the prevailing one. I don't believe its the same situation in all businesses and all countries in the world.

How come that your healthcare customers use your application when it is written in an old-fashioned language which nobody knows, as you say, and which uses emulated database access? I believe, the reason is in accordance with my statement: "What is the most important for the customers is the end result.".

[Tom]

It's getting harder every day. Every single day.

But, hey. Do as you like.

[unixkd]

I want to sincerely thank Slavkodam, Tom, Roger, Kinsis and others that had contributed to this topic. You are all great.

I have been greatly educated by your contributions. I have a better perspective of the situation and what is influencing individual suggestions.

I was surprised when I received emails from a friend who does programming business in a dialet of Basic for windows not vb and a frequent reader of this forum telling me how rich the discussions had been with appreciation.

The only thing that is constant in the world of programming is change. What we call modern tools today may not be modern tomorrow. It depends. Few years back we sold our accounting system to a client. Few years later the engage an international consultants to restructure their organisation. In the process they recommended oracle financial for them. Upon implementation they realised that yes oracle is popular but it could not give them up to 30% of what our solution was giving them. All the user are now clamouring for our return. This way I cannot agree less with Slavko when he said that results matter.

For now Xbase++ with SQLExpress and Express++ satisfy my needs. Our products are big but we operate a very small company.

From Tom perspective he is right. But I am sure that Tom migrating his healthcare to the modern platform will be a Herculean task. Much daunting than what happened when migrating from clipper before the coming of Xbase++. Such solution will have to be completely re-writen.

Rmchart which was written in powerbasic many years ago has been intelligently added to powerweb and express++ even though powerbasic technically reached its end in year 2012 when its development stopped.

If Alaska could think of how to make xbase++ work with language like python that will be great.

Once again thanks for your contributions

Joe

[Tom]

Hi, Joe.

I thought we were mainly talking about new projects here. I wouldn't start a new project with Xbase++ or any of the other Xbase-dialects. This is not a question of what can be done with that, but a question of what future this will have. It is a 32-bit-4GL-Compiler, built by a small company and used by a few hundred of developers all over the world. The community is getting smaller and smaller. We have a Xbase++-conference in germany starting at the end of this week. In 2007, we had 200 developers from all over the world here. This year, we can't even sell the 40 seats the conference room has. The conference starts on friday, today we count 15 attendees and 6 speakers. Alaska will not attend, although it's in Germany. We are waiting for Xbase++ 3.0 for ... I don't know. Yes, Xbase++ is a great language, it saved my company, it saved my life on the economical side, I love to work with it (except the horrible Workbench). But it comes to an end. It's the same for all the other dialects. There is nothing really vivid. A few guys are struggling and fighting to get updates and new stuff build in, and the guys using it are getting older and older. It simply doesn't have a future. All the other techniques have millions of followers.

Yes, the number of features used to be a deciding factor, and if our own application wasn't so full of them, we might not be around anymore. A follow-up build with different techniques would be a huge success with ten percent of the features. Fifteen would be sensational. But this is no real question. There is no alternative. And this is not only an opinion.

[k-insis]

xpp+sqlexpress solves our need for xpp based programs -> {oracle,postgresql,mariadb} since 2005 ; where it is too little, app server side php/python and stored procedures on servers help . It works reliably and reasonably fast, support is fast and good.

On python xpp interface

In 2014 Lorenzo Succi did a work on python <--> interface and source still exists.

For now Xbase++ with SQLExpress and Express++ satisfy my needs. Our products are big but we operate a very small company.

If Alaska could think of how to make xbase++ work with language like python that will be great.

Joe

[SlavkoDam]

Tom wrote:
We are waiting for Xbase++ 3.0 for ... I don't know. A few guys are struggling and fighting to get updates and new stuff build in.

Its sad but its all true. The reason for this might be that Alaska stuff don't want to take into account the contributions of other external Xbase++ developers. Alaska developers are not the only one in Xbase++ world, and they certainly don't know and can't do everything. My work with Power libraries are constantly neglected, disputed and denied by Alaska dev.team. They even don't want to list all my Power libraries on their Technology Partner page. For some reasons they don't approve them.

I modestly think that by extending Xbase++ with capabilities of PowerSql, PowerWeb, PowerCrp, PowerPar libraries, which none of them exist in Xbase++, its strength will be higher, its modernization will be improved, and the benefit for Xbase++ programmers will be large. This might be a good investment in the future.

[Tom]

Hi, Slavko.

Although I understand your frustration, I don't think it's a good idea to publish conversations that don't meant to be published. Besides, in 1999, I first tried to convince Alaska to integrate Roger's eXpress++-framework into the installation package, because it was (and still is) a great (the best) tool not only to move fast from Clipper or CLI-mode to GUI, but to build applications. They told me (and repeated that in public), that they were thinking of that, but they didn't have the capabilities to support products not created by themselves. In addition, they wanted to keep the 3rd-party-community alive. Besides, caring the responsiblity for something they don't know completely, might be a risk. Maybe that kind of thoughts were the reasons for the recent decision concerning your products. But this is not the place to discuss this.

[unixkd]

Hi Slavko and Tom

I too can understand the frustrations of Slavko when you produce great products without appreciable returns. I equally understand Tom apprehension concerning the future of xbase++. Both of you are right. Developers worldwide like to always be on top of their game and Alaska as a company is helping in this situation.

One thing is certain. The best product don't normally be the most successful in the market. You need to understand the market dynamics. Xbase++ is a great language but Alaska is not keeping up with the changing world. If I can recall 3.0 was promised over a decade ago and at the moment the status is unknown. That is not good enough. They need to talk to the users.

Just like Tom said the world is changing and companies must imbibe the concepts of changing strategy. Keeping quiet is not good for Alaska and customers.

Joe