Hi,
Consider this as a reply to Ola's rant on the reporting editor...
Although we have better experiences than Ola with WX and although we still like many concepts of it, we have to admit that quite a lot of stuff in there is too often half-baked. That's one of the reasons that since several years we have been moving more and more development to .Net (C#) (especially .Net Core now as that is a fully multi-platform language that is open sourced by Microsoft since 2015).
Sure, we'll continue to use WX (we own all three products for many many years) but it has never been automatically the default platform of choice (although we know it so well aside of other technologies). We think it can add value in prototyping and building quick proof of concepts. As well as for solutions limited in scope with a high level of isolation not requiring a lot of integration with other platforms or with a temporary character. And we certainly will not select it for business critical software or solutions that require a lot of scalability.
You’ll probably ask: Why, what are the main reasons for such bald statements?
So far our rant…
Sure we’ll continue to use WX (at least WD, not sure about the rest), but only where we feel it will match the needs, requirements and likely where its scope and scalability requirements are limited as well…
WX has some great ideas and great concepts, they just no longer fit our needs or they are too badly executed for us to bring added value. Just too often WX resembles the things you get with it in the box: glossy, shiny items... But if you take a closer look, you'll see a mediocre build quality. That's what WX is for us after all these years of using it: a gadget ! So, use it wisely ;-)
We’re sure WX can serve many of your needs as it does for certain of ours.
Just make sure you're using the right tool for the job!
My 2 cents,
Peter Holemans
A long time WX forum contributor
Consider this as a reply to Ola's rant on the reporting editor...
Although we have better experiences than Ola with WX and although we still like many concepts of it, we have to admit that quite a lot of stuff in there is too often half-baked. That's one of the reasons that since several years we have been moving more and more development to .Net (C#) (especially .Net Core now as that is a fully multi-platform language that is open sourced by Microsoft since 2015).
Sure, we'll continue to use WX (we own all three products for many many years) but it has never been automatically the default platform of choice (although we know it so well aside of other technologies). We think it can add value in prototyping and building quick proof of concepts. As well as for solutions limited in scope with a high level of isolation not requiring a lot of integration with other platforms or with a temporary character. And we certainly will not select it for business critical software or solutions that require a lot of scalability.
You’ll probably ask: Why, what are the main reasons for such bald statements?
- We just don't want to be too dependent on PCSoft as a vendor whenever we hit a wall. Sure there might be a workaround in most cases but to our experience often building such a work around takes 10 times more code, 10 times more time and creates 10 times less maintainability. You are on your own in those cases...
As an example we've been going around in circles for almost 6 months with PCSoft support on their webservices consumption engine. We clearly showed them on the basis of examples and explanation documents in both WLanguage and C# that encoding a string passed to a webservice parameter of 'ComplexType' in the wsdl (with or without the <any> element) is in contradiction to the worldwide XML standard. It should insert it as an XMLNode (an XML insertion so to speak) rather than as an XML encoded string. After many iterations, PCSoft keeps on claiming that this is not a bug but an 'enhancement request'. After polling many times if and when this would be planned we finally got an answer: it is not planned for WX21 and not for WX22... The 923 other gadgets for the end of 2017 have all priority we assume. How can we work with a tool that doesn't follow global standards and thinks their own half-baked ones are better, let alone that it may never be fixed. Not only does the webservice call return an error out of WLanguage because of this encoding, doing the same web service call in C# requires even less code than in WLanguage and it executes as expected. So far their so called ‘5GL’…
. - The WX platform cannot be extended... PCS thinks it is the only one who can develop its platform and keeps it closed up to a ridiculous level. All sources are encrypted, extending the language or features is impossible, exposing metadata (introspection) is only done through 'Search', building automators and code generators is made impossible, exchanging source code between releases is painful to say the least, etc... It is completely the opposite to a trend that has been going on for many years and that to the benefit of many other technologies out there that shine because of their community and openness. Hell, they can even make a lot of money out it...
As an example, more than three years ago we published our WX OO framework on the PCSoft repository. It has been downloaded many times and we know many of you have taken over many of the concepts that were part of it. One of the ridiculous limitations is that the code it can generate cannot directly be saved into a WLanguage source file so one has to create the class in WX, and copy like an idiot the generated code. Although we (and we’re sure many others) have requested some more openness in this area for at least 5 consecutive years so we could generate WX objects out of the IDE or runtime ourselves, there is the deafening silence on the other end of the line. Part of their paranoia (or is it complete ignorance), we guess…
. - Because the WX platform is so closed, it is also extremely niche with a very small community of people that help one another like on this forum, but it remains a ‘plaster on a wooden leg’ as we say. Today, a large community that can extend a platform is rather the norm. And the size of and adoption by this community will decide on who will become a winner and who will stay a niche player forever and vanish in the end. With their current philosophy PCSoft will remain in the latter group and vanish ultimately, we’re afraid.
. - The platform contains great ideas but the execution is... well... not so great. The company shows of its 900 something 'New' features every year which in general makes sense and adds certainly value in specific cases. But the problem is that once these features have been implemented and have been announced with a lot of ‘pouha’, the evolution stops and the focus is on the next 900 something new half-baked gadgets. We’re missing constant logical evolution and improvement instead of this yearly recurring ‘surprise!’ where one asks: ‘where are the improvements to the existing stuff’… A public roadmap, with a subscription model seems more modern to us…
As an example in WX19 or WX20 (I don’t recall correctly) PCSoft introduced the native usage of ics calendar events trough the Appointment variable. Great, we had written our own, so we could as of now move this over to the WX native runtime delegating the maintenance to PCSoft. But… After working with it, we noticed one immense limitation of the PCSoft implementation: You couldn’t pass the calendar method to it in order to alter or delete a calendar event. We proposed as a suggestion several ways to do this like foreseeing a generic member for additional information on the Appointment object that can be freely used by the developer to pass on specific elements to the generated ics. A quick win and extremely easy to implement for PCSoft… Up until now nothing happened and we don’t expect anything to happen soon neither. Our software still uses our own implementation which is better and more flexible than PCSofts one. If we were able to extend theirs it would probably be better…
. - Too many features are hard bound to physical controls. We love the calendar, agenda, planning, the new (currently half-baked) rich text control, etc… The problem is that they are often not very well implemented and require a handle to an instance on the GUI in order to be fully exploitable. We write our software in general first as a black box without a GUI, so it can be consumed from whatever source (window, web page, mobile device, web service, rest api, …). This not only makes your software platform/front-end independent by definition, it requires as well that all these fancy WX objects can be managed fully in memory without a GUI implementation or a handle to a control of the same type. Missing this makes development certainly not 10 times faster because you need to write your own.
. - Missing OO features and the missing of an object-relational broker (ORB/ORM). By definition all our software starts off from writing the business objects (The M out of the MVC (Model/View/Controller) pattern which is available out of the box for about any other development platform out here, be it web, mobile or fat client). Most other modern languages have an object relational broker in combination with that to do all the I/O stuff in an automated way from the business objects to the relational database. Or there are open source or commercial extensions that can do this. This ORM also abstracts out any database specifics, so you don’t care about being it Oracle or SQL Server and several even do the automated schema changes based on changes to the business classes. (You really thought HF was the only capable of keeping the schema in sync?)
If you have a look at .Net Core and and the .Net Core Entity Framework (the .Net open source ORM) you’ll see how easy this works and how much more advanced it is to any of the WX OO Language features. You can find great tutorial video’s on the .Net Core Entity Framework from a developer point of view on [courses.devu.com] (I am a lifetime member since 2006).
. - Webdev still not being where it should be… We bought WebDev every year as of version 12 and have a few apps running on it. It still is far from being a valid web development platform. It lives its own live, still works around html tables to do a basic layout, has no full CSS integration, has many objects unmanageable out of JS (Try to manipulate a WebDev looper, table or treeview and its elements out of JS… Simply forget it), and has the same problem as the rest of the suite: so f****ng closed while web technology is by definition so open… On top of that, the application server is ridiculously slow. We’re rewriting the few WebDev apps that we have currently completely in ASP .Net Core (combined with .Net Core Entity Framework and ASP .Net Core MVC)…
. - PCSoft Support… This is a real showstopper for us. Although PCSoft support tends to reply within a reasonable delay in a polite manor, we tend to call it ‘the big black hole’… There is no self-service portal where one can follow up his tickets or communicate with support on a specific ticket or upload resources, etc. There is no openness or visibility whatsoever on reported and confirmed bugs and what their status is (Abandonned + Reason, Confirmed, Planned, In development, In test, Released in version x, …), what the potential workarounds are or what the estimated date of release or delivery will be. Nor is there a knowledge base in which one can first search if a bug is already reported and what the status or release level of the fix is. How many of us are creating the same sample projects to prove a bug or loosing time in analysing an issue to find out it concerns an already reported bug as a simple search on a knowledge base may have pointed out? What a waste of time…
. - And to finish: The lack of international vision and ambition of PCSoft… We’ve been loyal users of WX software as-of 1999 and have updated loyally every year (1999 WD 5.5bInt, 2006 WB12, 2008 WM14) but there is one consistent given: the ambitions of PCSoft towards and its respect for customers outside of the French speaking world is limited (Personally I have easy talking as I am quadrilingual including French). We have software running in three continents (EU / US / AS). We simply can no longer afford to have runtime releases in English that are at 6 to 8 months behind. Certainly not in areas like web or mobile development where stuff evolves at the speed of light. We’ve always worked international (and have done and still do projects in France) and it is a recurring thing with many Frenchmen and French corporate culture… We assume it is a language barrier where the reading, writing and speaking skills in anything else than French remains a huge hurdle… Our advise to PCSoft: If you can’t do it yourself, you should surround yourself wisely with people who can and open up those doors and windows to break out of that ‘carcan’ and tunnel vision (Please: Break free!).
So far our rant…
Sure we’ll continue to use WX (at least WD, not sure about the rest), but only where we feel it will match the needs, requirements and likely where its scope and scalability requirements are limited as well…
WX has some great ideas and great concepts, they just no longer fit our needs or they are too badly executed for us to bring added value. Just too often WX resembles the things you get with it in the box: glossy, shiny items... But if you take a closer look, you'll see a mediocre build quality. That's what WX is for us after all these years of using it: a gadget ! So, use it wisely ;-)
We’re sure WX can serve many of your needs as it does for certain of ours.
Just make sure you're using the right tool for the job!
My 2 cents,
Peter Holemans
A long time WX forum contributor