How many Developers are using Xojo?

Print
https://documentation.xojo.com/api/printing/print.html
Input
https://documentation.xojo.com/api/os/input.html

You might not use them but they exist.

Only in console applications, it appears, which is why Iā€™ve not come across them.

John,

As a former FoxPro dev and past technical editor of FoxTalk magazine, I have a few thoughts.

If this is FoxPro for DOS or Xenix, check out Recital, which is fully compatible with text-mode FoxPro apps. For FoxPro for Windows you would be looking at Lianja (same company), which is less of a drop-in replacement but not too bad. This of course doesnā€™t address the concern for finding devs who can hit the ground running or who will stay around once hired without fear of having more current skillsets go stale. However it does remove the concern about hitting a wall with Windows, and adds macOS deployment. (IIRC, Recital is Linux-only).

With both FoxPro and Lianja, nothing limits you to the DBF and related formats of the built-in database. You can move to Postgres for example, and get away from the built-in DB ā€“ although that was certainly no slouch in the performance department; its query optimizer is now part of Sql Server and has been for a number of years. Lianja has evolved the built-in DB in some nice ways too.

I have personally found Xojo restores the enjoyment of building end-user apps on desktop that I recall from FoxPro, with the advantage that Basic dialects are more ā€œaliveā€ in the marketplace and arguably more apt to stay that way than XBase-family languages like FoxPro. But my use case for / experience with Xojo is strictly for desktop targets, with backing store in Postgres. I also do all my own SQL. I canā€™t speak for other approaches / DBs.

Since you would be faced with a complete rewrite of the FoxPro apps should you elect to move away from the platform and language, really everything is open to consideration. My own path was through classic ASP / VBScript to ASP.NET MVC 5 and combination of C# and VB.NET because thatā€™s where the demand / $$ were. I think the last FoxPro app I maintained was sold off around the year 2000 and AFAIK was eventually rewritten in Java talking to Oracle, although hilariously they could not wring equivalent performance out of it so the successor company hired me for a time to keep the old code going.

This is not the venue for me to hold forth on Xojo vs alternatives so Iā€™ll just leave it at that.

1 Like

Bob

Thanks for the reply. Iā€™m sure I bought a bunch of your Foxtalk magazines back in the day when we were developing in Visual Foxpro. I started with dBASE and then move on with the clones and then eventually to Foxbase and finally to Foxpro for DOS and Visual Foxpro after MSFT bought out Foxbase.

Re-writes are nothing new to me having migrated a number of commercial apps from VFP to xojo. There were many other iterations in between.

Iā€™m also familiar with Postgres and SQL Server since we use both of them in house and externally for a big client.

Weā€™ve also used the Sybase ODBC driver to convert DBF files to Sqlite, and this worked pretty well but there were some issues that were impossible to overcome. Fortunately, none were show stoppers.

Iā€™ve looked an Lanja in the past but it seemed like there were a lot of components that were still in the beta stage and not ready for development. Not sure if they have progressed to the point where it would be a reliable alternative ā€¦ or should I say any more reliable than XOJO. Again, might be just as hard to find someone with expertise in Lanja as opposed to XOJO.

For desktop apps, VFP has certainly held their own against some of the other alternatives out there, but as time goes on, the proprietary nature of VFP is becoming more and more of an issue.

I never did use FoxPro but did for many many years use Clipper and then the ill fated VisualObjects.

My concern with Lianja is less bugs (they seem pretty responsive to users, judging from their forum when I was on it many months ago) as that they are leading with a more low-code approach and their default framework / scaffolding / UI designer seems overly oriented to CRUD apps with a certain look and feel. I was concerned it would be too limiting. But I planned to take a closer look later next year when they add C# as a supported language, which is intriguing (currently they support FoxPro, Python, JavaScript and PHP; this in itself is kind of an interesting idea, where the scripting language is just basically a plugin). But I am a little leery that they tend to talk a lot about something called ā€œthe Lianja Wayā€ whenever someone is struggling to accomplish something overly specific. When a developerā€™s requirements is met with ā€œyouā€™re doing it wrongā€ thatā€™s a bit of a red flag.

But I also get the sense they are upping their game a bit in that regard so weā€™ll see how its doing a year down the road.

The other thing that worries me is they seem to be pushing in the direction of selling cloud services for deployment, which can get pricey. Not sure if they have Xojoā€™s flexibility where you can manage your own servers if desired. I havenā€™t had the bandwidth to keep up with them.

Clipper was certainly popular but its syntax was just different enough that I was put off by it, especially since in those days I was making a lot of $ from customizing accounting software written in vanilla Xbase (dBase III really) and I needed that backward compatibility. And Foxā€™s compiler and underlying engine were plenty fast enough for line of business apps so the fact Clipper built a (rather large) .exe wasnā€™t that exciting to me.

It did but you could use Blinker to produce 16bit executables that worked with DOS extended memory. I built some pretty extensive applications using it. Including one that used to run multiple clinical trials all at the same time. I loved the codeblocks, an extension to the dBase macro capability. It allowed you to compile and run expressions at runtime, allowing formula within databases to be loaded and executed with parameters from the programs. Made for some pretty nifty data driven applications.

1 Like

dBase still exists. You can visit their website.
But it has nothing to do with the approach they took to Fox.

The .NET offer never convinced me.

XOJO is excellent for many requirements that are in the market. I hope it evolves to make it easier by taking advantage of the data and using visual programming without coding.

What does ā€œvisual programming without codingā€ mean to you?

A visual designer that you drop controls on and you do minimal event hooks to get the control interactions and visual the way you want them is what you already have in Xojo.

If you want ā€œlow codeā€ then youā€™re talking something more like Lianja that understands DB table relationships, you drag and drop DB tables into a designer and hook them together with relations and live with the abstraction that results from that. Thatā€™s a way to knock out CRUD apps quickly but even for internal use, clients often have very specific requirements of how they want it to look and behave, or they are having you port an existing product and they want to minimize retraining and so want it to not upset existing workflows or look very different. You can automate procedural steps away but you canā€™t change or add much.

Because of this I am not interested in attempts at drag-and-drop-and-done development, which never really succeeds anyway.

3 Likes

For me it was my experience with LabViewā€¦ where you connected components with information wires like a circuit board.

-Karen

3 Likes

Various languages Iā€™ve known and used have attempted to create such a system. For example VB3 attempted to make a datasource for any ODBC system, you could then like pretty much any control to a field in that that datasource.

VisualObjects had a similar arrangement. Going back to the dawn of time dBase III+ also had a system that would allow you to setup a get on screen that linked to a table / field / record. 4D was much the same.

None of them ever created something that actually worked.

Take for example a real database. If you have as a field called Gender, which allowed you to store Male and Female (and any other options you may wish to allow). The problem is you wouldnā€™t actually build a database in that fashion. You would have a lookup table for the text versions of the genders and a code value that you actually stored in the person record. It may be M, F (or 1, 2, 3 etc). None of the systems dealt with that type of issue in any way at all.

You ended up creating a drop down list and populating it from one table. You would then link the ListIndex (or SelectedRowIndex) to the field in your person record. All of which you ended up doing yourself. A very trivial example but one that would crop up a lot. Iā€™ve jet to see any system cope well with it.

There is (or certainly was) an element on the roadmap for Xojo that talked of something similar.

You touched on a relevant point in the current market.

Many offer NO-CODE, others MIDDLE-CODE, and others complete manual coding. Whereas some programmers say: they donā€™t want to NO-CODE because they want to control all aspects of a system.

For me would be a tool that allows you to generate a prototype very quickly without coding, verifying the operations with the users, and completing it with little code. Finally, do it professionally the new system. The three stages mentioned generating a system without diminishing the full power of the tool with the ability to code everything that one wants to implement.

What happens in the market?

What I wrote is currently done by large companies with their technology team and the most consultants.

They use a NO-CODE tool to make a prototype. If it works with users, they complete it with MIDDLE-CODE. With orders made by the users for the new system, they do it with manual coding.

XOJO can cover all the phases I mention. No-Code, Middle-Code, and Full-Code. But Xojo needs help now.

Visual programming is not just dragging and dropping. So is applying business rules visually, among other details.

No PRO uses NO-CODE, unless they want to make a mockup, hardly a prototype. Prototype demands you use a capable choice/language, just lacks completeness. Mostly of it will be done using the final choice.

The best tools have helpers, IDEs or GUI designers, that helps devs with with features as drag and drop components and setting their properties, but internally all the work ends as code (hidden or not) that can be even further customized.

I hope some day XOJO ends as a full code able to customize using any editor, even directly in a GIT account, but having an IDE translating GUI coded designs to visual drag and drop editable ones.

1 Like

You just described what no-code is. You also made the mistake that drags and drops only works for the GUI.

Precisely some NO CODE tools are managing to interpret business rules visually.

This market is growing for a reason. I remember you are not my invention or my ideas. I leave you an image.

image

Reference:
https://www.researchandmarkets.com/reports/5440525/application-development-software-market-size?gclid=CjwKCAiA-dCcBhBQEiwAeWidtcL7Xz_MscWj_Xgn3NXvV-3IUqAIbw16LoqHQVOXgR20TYpt41V7txoCkvgQAvD_BwE

Reference:

1 Like

Forecast by whom, I wonder?
In my opinion (feel free to have your own), little of real value can be made using a no-code solution.

Nope. A no-code tool intends to solve tasks dragging and piling ready logical blocks and setting some properties for those blocks instead of writing the exact code you need to solve that task. Something like ā€œIF a > 0 THEN a = b + 1ā€ can be a pain costing many seconds to be done.

There are a lot of articles and blog posts along this line pointing out this growth market and encouraging developers to understand low-code tools because they will have to help departmental / citizen devs clean those up, document and maintain them and connect them with other systems.

But to me this is just pointing out the obvious fly in the ointment: any idea thatā€™s truly useful has to be maintained. Eventually the bean counter who created his dream system with drag and drop gets run over by a bus and someone else has to understand and use the system, as well as figure out that he was siphoning off a few cents at a time to his own bank account. Itā€™s just not a sustainably governable idea.

Weā€™ve seen this movie before with spreadsheets, desktop databases, and more. Thereā€™s no shortcut to, or substitute for, correct analysis, choice of best tools and practices, good architecture, appropriate test coverage with the right kinds of tests, and so forth. You can have things correct, cheap, or fast ā€“ pick any two.

I predict a spasm of low-code that is choked in the crib by its own shortcomings.

3 Likes

Iā€™m not talking about with a NO CODE tool can do something of value.

Iā€™m trying to say that it is growing a lot in the market. NO CODE offers a way of interpreting all the business rules of a system in some tools, which is the Itā€™s the new way of doing things (full visual mode).

Some are offering SAAS services only using NO CODE tools.

Some people said the same thing when Visual Basic came out in the market as a way to move objects on a screen and drag these objects.