Ok... so I should first say that I very much have an appreciation for all of the awesome things that I can do with Deluge.  It really can be quite powerful in a variety of ways, and allows for all kinds of customization that otherwise would not be possible.

Admittedly however, I've had days (and sometimes late nights that turn into early mornings) that I end up feeling like my head is going to explode when coding in Deluge.  Now let me emphasize something here... Deluge is a terrific language... but... it suffers enormously by the glaring lack of basic functionality within the web-based IDE.

So some of my gripes include:

1.  There are several variations of Deluge running across the various Zoho applications, and with various degrees of functionality.  Some are better than others - the best of these being being almost tolerable, the worst being barely usable.

2.  Depending on context and the relevant module, I can usually enter in an item ID, or a PO ID, or whatever other ID to run a test execution of my code with.  This is great, except that I have to enter the ID in every single time I want to run my code (CRM being one notable exception).  It's not a big deal, until you're testing and making changes in your code and end up having to deal with it 100 or 500 times... so much as to the extent that I've found myself writing key macros just to automate entry of the IDs while I run test executions.

3.  Depending on the module, error reporting is frequently misleading, often without providing line numbers (or frequently the incorrect line number), or using language that's either too obscure or written such that it really is a chore to decipher what it's even saying.  AppleSoft Basic provided better errors in 1976.  Granted, there are appreciable differences, but I stand by the fact that in 2020, even the most rudimentary basic ways of developing code should always give you a line number.  Always.  Always.

4.  In addition to specifying the line number, why not just highlight the point in the code in red so that you can just go right to the problem area and get down to business.

(Feel free to pass points 3 & 4 to the Sites and Commerce Face teams as well.)

5.  How about incorporating break points to halt the code where you can evaluate variables?

And so after contemplating the various issues, thought I'd put forth one possible approach that I would see as a way that could potentially catapult Deluge into the next level and beyond, while also reducing the anxiety experienced by seasoned programmers who relentlessly find themselves pulling their hair out, wondering why this otherwise useful language is so unbearably painful to develop with. (Granted, I can't speak for others, but I know there are others who have voiced similar sentiments.)

So if I were to imagine a path for redemption for Deluge, it might be by way of using Visual Studio Code as a catalyst.  Visual Studio Code has quickly and increasingly become one of the most commonly used code editors in recent years - largely because it's a Microsoft product vetted through years of development since Visual C++ was initially launched around 30 years ago.

It's become so ubiquitous that there even already exists a very basic code formatter for Zoho's Deluge as one of the available extensions - and could provide a starting place for more substantive integration to begin to take things a step further.

What could really take Deluge to the next level in this regard would potentially incorporate the use of a "live" connector that could operate between a user's Visual Studio Code installation and the Deluge Runtime Engine.  In essence, it could serve to automatically upload the most recent versions of an edited Deluge script from VS Code into whichever relevant Zoho module is in context, as well as invoke test executions of your code directly from the VS Code IDE.  Furthermore, the DRE would subsequently be able to report back error codes (with line numbers and relevant code to be highlighted) in realtime across the link. 

Taking it even a step further, such a link could also serve as means of proving a data connector to providing context while working on your Deluge code.  In other languages (and their related development environments), an ODBC connector can often be instantiated... not only during runtime, but also "live linked" during development so that you can develop your code while contextually aware of the data and relevant data types you're coding against.  

And because the aforementioned functionality has already been previously incorporated into VS Code for other languages, the UI in VS Code is already primed to be able to handle these tasks without reinventing the wheel.  Things like breakpoints, watch variables, data connectors are already either in place, or can likely be adapted.  This of course would dramatically shorten the time and effort needed to make something of this sort feasible. 

In effect, hardware debuggers for embedded solutions (like a microcontroller in a microwave oven or a cable TV set-top box) work the same way.  The execution of code, breakpoints, uploading of code, etc, are all traversing a simple link.  Typically, such hardware debugging in this regard can even be run remotely - even across the Internet over port forwarded IP addresses.

Ultimately my point is not to educate anyone on how debugging works, as I'm sure that Zoho's engineer's are already well versed in these concepts... but only as a means underscore that the model of debugging over IP is commonplace, and could probably easily be applied to the Deluge Runtime Engine as well.

Now I could be wrong, but if I were to guess... I'd be inclined to believe that much of the functionality that I've highlighted above is probably already in existence.  I say this not because I know of some secret codebase I've stumbled across or have some sort of secret insider knowledge that there's some stash of advanced tools lying in some hidden Zoho vault.

Rather, I say this only because so many of the aforementioned issues that I point out here would have been addressed long ago if the software engineers at Zoho were forced to use the same web-based tools as its client base.  I can't think of a single engineer that go to such lengths as to create a language like Deluge, and then not build in the most basic rudimentary means of providing error codes, debugging, and usable feedback.

Based on that assumption, it's almost a certainty IMHO that there are in-house tools in existence that provide this type of feedback, but few within Zoho's customer base have expressed enough dissatisfaction so far in order to warrant the efforts that would be required to bring such functionality to web-based Deluge IDE used by Zoho's client base. Naturally this just comes down to priorities, and would be the case in most any organization, these priorities are typically determined by the collective voice of its customer base.

Sometimes however, these needs might be a step removed from what the customer states vs what they don't know they should be asking for.  A business owner might, for example, choose one platform over another... not because of the degree of feedback provided by the web-based IDE used to implement customizations, as that's not even on their radar.

What might be on their radar however is that one platform has vastly more third partly customizations available, which might be the case if developers are much more inclined to develop for it, which can a directly impacted by the tools they have available to work from.

So all that to say... if it's the squeaky wheel that get's the most oil, "SQUEEEEEEEEEEEEEEEEK".

Thanks for consideration of the aforementioned issues.,

Bryan