David Schwartz

NOTE: I'm not sure if this best fits into Network, Cloud and Web area or the Cross-platform area, as it seems to span both. A while back before I started working with WEB Core, I asked some questions here about how to work with threads to synchronize calls to APIs. They created a lot of noise, in part I think because there are several different multi-threading libs and idioms that offer a variety of features and benefits that fit some needs better than others. WEB Core came out shortly after that and I started playing with it. They take Dephi code and run it through pas2js to transpile it into javascript. They were able to modify the input language slightly to make it easier to map code into common js idioms, by providing an [async] attribute and an await(...) method. There's also an async; tag that can be placed in certain places after a method definition. I've been working with this stuff for quite a while now, and I often forget to use one or the other of the above annotations correctly. It doesn't help that the compiler does a poor job of keeping attributes attached to the lines they affect in the class headers, which causes other headaches. I wrote something last year that is a multi-step process that involved a ton of API calls in each step. Although the idea was to make much of it run in parallel, the syntax requirements and sync dependencies made it quite messy to accomplish. Maintaining it got to be a nightmare. However, TMS just announced that they are incorporating a fairly new open-source async library into their stuff that appears to solve a lot of the complexity issues I ran into -- and I bet a lot of folks who don't use TMS products for this have as well, since it addresses a quite generic problem. Here's the post in their blog where they announced it: https://www.tmssoftware.com/site/blog.asp?post=1296 There are links in that article where you can find the original source code (on github) where the docs and code libs are found. This approach does not require any changes to the language, yet offers a clear and fairly simple approach to dealing with the async nature of remote APIs without undue burden on having to manage tons of threads. TMS has retrofitted it into one of their FNC libs (the FNC Cloud Pack) that can be referred to for your reading pleasure, and it looks like they might be expanding it to other libs as well. The point is, this library is written for Dephi and is fully independent on any of TMS' own tools. It might be worth looking at if you work with code that's a lot more convoluted than you like due to the need to synchronize a lot of calls to external APIs and services. I haven't had a chance to do anything with it other than read through the documentation; but after the nightmares I had from the sync-related code I was working on last year, this lib looks quite promising. I can see why TMS likely chose to adopt it -- not just for new code, but they're even making a considerable effort to retrofit it into their exising packages, which isn't something that's ever done without quite a bit of close scrutiny.

If you prefer working from the command line, why not just use something that's oriented that way? I mean, you don't need a language as complex as Pascal to write simple scripts. Try playing with bash or sh or ksh or some other shell scripting language. The thing you're missing in just focusing on the command-line is not the GUI, but the entire Event-Driven ecology. That's what really sets Delphi apart from even simple Pascal. if you don't want to mess with a UI, then consider playing around with back-end services using one of the many REST frameworks that are available for that. Nobody gives two craps about Pascal today. Delphi is still alive and kicking because of the VCL, which is mainly an EVENT-DRIVEN FRAMEWORK. That's how it SUPPORTS such a rich and complex GUI environment. The basic Pascal language and RTL is available to command-line apps, but nothing from the VCL or FMX frameworks are, even though that's where 99% of the VALUE lies.

Well, writing web apps in Delphi is not something I'd want to do. They have to be built as something like ISAPI modules (basically, DLLs) running in a Windows host. Not my idea of fun. You really should look into TMS WEB Core. It's sort of an "add-in" to the Delphi IDE that lets you use a slightly enhanced version of Delphi (without inline var support yet) that gets compied down to javascript. You can hit the F9 key and your app will open up inside of a web browser. It's really awesome to see in action. They also have a version that runs in Visual Studio Code. Visit their website to learn more. I think it's quite revolutionary. As far as hosting goes, hosting is hosting is hosting. All that stuff you might see as "clunky" is just the crap a vendor ads into the environment that you have to pass by while getting to your destination -- like how the grocery stores always put staples at the back of the store and all of the newer and more profitable stuff towards the front so you have to walk by it on the way to get your milk and meat. If you want to get some experience with hosting, grab something like LAMP or MAMP or WAMP (Linux/Mac/Windows) and install it in your computer. It loads up everything you'll need to do web development on your local machine. Win 10 includes a Linux subsystem that has these things included as well. A lot of people use FTP to upload stuff to their server; I just prefer to stick with cPanel hosting and use it's FileManager to upload files to the file system. It doesn't let you copy a file tree, but that's easy to solve by making a zip file of your file tree, uploading it into the folder where you want it, then unzipping / expanding it there. It's way easier than messing with FTP IMHO. If you're working with a Windows server, you'll need to use RDP to get into it. Linux can use SSH which just gives you a shell, although that's only avilable if you have a dedicated server with root access; otherwise, just use whatever your control panel offers (like cPanel's FileManager). When you visit different hosting providers, if you look at enough of them, you'll find they're all selling the same few distributons of Linux, or some Windows version. If you're using Delphi to build a REST service, you'll probably need to use a Windows host -- unless you can generate a Linux target.

Thanks for this. Is it useful without a run-time license for DevEx? if you use generic Delphi code that can be tested in Delphi then loaded somewhere to run under DWScript, can you get by without DevEx?

I'm curious if anybody knows of any FOSS Delphi interpreters. TMS has had one for quite a while, and I worked with it on a project many years ago. But I think it's overkill for what I'm looking for. Besides, it's not FOSS. What I'm interested in is building a REST service that runs on a standard Linux host (eg., CentOS) and has a way of adding services by uploading a source file written in Delphi rather than having to upload compiled code. Delphi purists will say that's way too inefficient, but It's not like running interpreters on back-end servers is an unusual thing, since most such services are written in php, python, and even VB. Anyway, it doesn't need to "run fast", as long as you can easily spin-up multiple servers running the same code. I don't think it needs to support 100% of the latest Delphi language features, maybe just to D7 or even the version after D2010 with stable generics. As an aside, I cannot comprehend why Delphi has no support for Linux except for distros that conform to specific UI needs, when most people want to use Linux to run services, and most Linux hosting is all headless. There should be a way to build headless apps (ie, no UI parts) for common Linux distros in all Delphi versions.

I hate SOAP. I've used it on a couple of Delphi projects, and worked on a couple more where someone else was dealing with it, and the amount of effort needed just to get it to do basic stuff is horribly distorted. But when you're forced to interact with a system where all of their external APIs are built in SOAP, you're stuck with a pig-in-a-poke, IMHO. I know one guy who'd first build it in C# just to make sure the specs he was given were correct, because he said that devs frequently update the interface but don't update the public docs (that often involves two different teams). In one of my cases, Delphi's WSDL compiler generated crap, and I had to use a 3rd-party compiler to make my Delphi code work. Good luck with it!

The title of this thread is "Backward compability". That's referring to the ability to take OLDER versions of projects and build them in NEWER versions of Delphi, and it mainly applies to the language features and VCL. For example, you can still compile programs that declare 'object' types that existed briefly before the 'class' designation showed up. It has been deprecated for 25+ years, but it still works. You can even build old TurboPascal apps and there's a very good chance they'll compile and run without any issues. However, going from a NEWER version to an OLDER version has NEVER been supported. Needless to say, the error you're pointing to is not even in the language nor the VCL, so it's totally outside of Delphi's product domain. Meaning ... you're barking up the wrong tree. Third-party vendors frequently add updates to their libraries. Embt updates Delphi's language and the VCL very infrequently, mostly when a new major version is released. OTOH, companies like TMS Software (among others) frequently release updates based on bugs and requests submitted by their users. I don't know what library this is, but if it's DevEx, then I believe they update their subscribers quarterly. I've worked on projects where we used components from TMS, and in some cases, certain team members loved to complain about the frequency of updates, and they didn't bother doing them sometimes. I always update my libraries regularly, especially if there's something pushed out that fixes a bug or problem I encountered. If I do that and then commit an update, it's highly likely that someone who has not updated their TMS libs will encounter these same errors when attempting to build my code. That's not my fault! Nor does it have anything to do with either Delphi or "backward compatibility". (Frankly, it's a Project Management issue.) The moral of the story is, if you update a library and commit the code for it to your repo, then try opening that latest version on a machine that's got an older version of the library installed, then this is something that's VERY likely to happen. It doesn't matter what version of Delphi it is -- this is saying a property added to a class recently is missing from the version you've got installed on that machine, which is not terribly uncommon. You need to update the library, not Delphi.

If you've ever seen a FOREX dashboard built in Delphi running on a high-speed link, you wouldn't be asking these questions about whether it's possible. Yes, it absolutely is. What problem are you REALLY trying to solve? Also, shopping carts are DESIGNED to be STATIC, so they're an inappropriate example. Stock, bond, and FOREX trading are examples of HIGHLY dynamic apps, and Delphi has been used to build all of them.

When you've got a platform that has 64-bit integers that have values that actually range from, say, 0..27, and you think that having a dozen of them in a record is somehow more efficient than using an object with a single 64-bit pointer, I'm not clear what you think is being saved. Pointers might make use of half of a 64-bit data element, but there aren't a lot of applications that have that kind of dynamic range on the values they manipulate. Floating-point values ... ok, you get a little more precision for calculating the trajectory of things flying around the solar system. But for most routine programming tasks that the typical UI does ... it's way overkill. Consider that JSON is more or less a big record with labels but not types, meaning all of the data fits into 8-bit chunks, while accesses are usually done with very inefficient linear searches. So the first thing you often do is parse them into some kind of typed data structure as a more efficient container, unless you only refer to a few of the fields and then toss the the entire JSON string away. Records are fine when all of the data is managed by a single interface; but when you're passing them around and lots of different methods are touching them, and a change is made in one instance that's not propagated down the line and nobody else knows that the value has changed, they can be horribly time-consuming to debug. Or you can make a change that you do NOT want propagated but it DOES get propagated, simply because their use is mainly pass-by-value semantics but there's a hidden copy-on-write going on. But when a Record's data is managed by a single interface, you're just simulationg a Class. So ... what's the point? You're just having to write more management code that the compiler provides for free if you use a Class instead. It's like saying you won't sell your 1980-vintage car because you like being able to tweak the carb to assure optimal fuel efficiency, while ignoring the fact that electronic fuel injection can double or triple your overall mileage -- at the expense of having to trust that it's actually doing its job. I prefer to use Classes and trust the compiler to do its job.

What I mean is, can you compile for Intel platforms and test them? I seem to recall there's a translation layer that came with the M-series chips, but I don't hear much about it when it comes to using Delphi to build WinTel code.

I do my Delphi development in a VM running Windows on my Mac. I don't know what VMs let you run Windows on non-Intel Macs -- I think VMWare Fusion is the only one ... does anybody know for sure? (I don't have an M-series Mac so I'm wondering.) The most unstable part of my systems are the browsers that slowly eat up memory because javascript doesn't have any sort of memory management and nobody seems to bother freeing anything. From what I can tell, it's the same on all platforms because it's a javascript issue. Otherwise my experience has been that Macs are far more stable than Windows machines. My Win-based VMs implode from time to time, far more frequently than my Macs do. Again, what kills my Macs is because of excessive and uncontrolled memory leakage from javascript in the browsers. I totally minimize my use of browsers inside of the VM, but it still crashes for indeterminate reasons, just like every Windows laptop and desktop I've ever used. That's what I'd call the "Windows tax". I prefer the "Apple tax", thank you. There's also the well-known fact that Windows is targeted by hackers a couple of orders of magnitude more frequently than MacOS is. To deal with this, you need to run a steadily growing layer of screening tools that eat up a big chunk of the performance boost you get from upgrading your machine. This is the "other Windows tax".

Yes, this is rather vague. But if you're using D10.4 and it's a VCL DB app, then I'm guessing you're using some kind of TDatabase component to connect to your local DB? If so, it may be as simple as changing your provider interface and connecting to that. If you're using MySQL or SQL Server locally, you can connect to the same DBs remotely. But you could also be asking a more generic question, like what's involved replacing a local DB with a REST-based service API? I mean, you mentioned RadServer, so maybe that's what you're looking for instead? That's a whole nuther can of worms! But if that's what you want, then you need to start shifting how you think about your DB. In Delphi, using DB-aware controls, you're using a traditional client/server model where the app is simply connecting to a DB server and issuing queries and processing the responses. However, those queries tend to be invisible unless you're using explicit SQL queries. Issuing SQL queries for tables and rows is often a lot more overhead than what you want to do if you have a REST-based API -- in that case you need the queries to be more granular. A lot of client/server apps issue things like, "SELECT * FROM ...." and get back thousands and thousands of records, then filter them down. Using a REST-based API, it's best to issue extremely specific queries. Like if you're using a grid to show some data, you'd issue queries that only request to get the number of rows and columns in the grid. If it's a master/detail list, then when the user clicks a row, you'd issue a request to get the data for that specific row. Client/Server stuff often pulls everythign into memory when you open the tables. That is way to inefficient for remote services. If your app IS more of a traditional client/server app, they're you're going to need to re-do the forms and logic that's used to populate the forms, rather than relying on the underlying DB-aware components. There are some provider components that you can replace your existing ones with that add some level of intelligence to the underlying data management without needing a lot of rework on your part, but that would be more of a stop-gap IMHO. Another approach you can use retains the current providers but you'd want to lean more heavily on SQL and stored procs. If you plan it out correctly, the stored procs can be replaced by API calls to a back-end service with endpoints that call the same stored procs. Whatever approach you take, you MUST get away from the traditional client/server practices that simply open the tables and load the entire dataset into local memory.

That's why I prefer to buy stuff that's out-of-warranty and do my own upgrades. It's WAY CHEAPER that way! Most of what we're talking about is purely mechanical work; very little soldering is needed. Besides, I can't recall the last time I had any piece of electronics that failed and I was able to get it fixed under warranty. Seriously. FWIW, I spent most of today at a car dealer. I got a new car on Friday and while going through the paperwork yesterday (Sunday) I found that a few things that I kept telling them I wanted and hearing them say, "Ok, that's what you've got" -- but that ended up being far different than what was in the agreement they had me sign. It all had to do with warranties. If you want to find an industry that has figured out how to leverage people's fear of things breaking down vs. the cost to get it fixed, the automotive industry has perfected this to the max. My experience with electronics is they either fail in the first few hours of use, or they don't. That applies especially to computers and peripherals. I don't know how many dozens of computers are contained in the newest cars, but no matter what they say, most of them are NOT covered under ANY warranties. But they'll tell you they are -- or they'll say they're NOT just to get you to buy an extended warranty plan that you don't need, and when they fail they'll tell you they're NOT covered. I got this new car because my last car had a problem that originated with the previous owner. In spite of all of all the warranties and assurances that I didn't have to worry about ANY problems that might arise with my electrical system (it's an EV) they were all just a big pack of lies. My fast charge port stopped working, and they wanted $6500 to replace the entire wiring harness in it -- even though the warranty I paid $5k for was supposedly designed to cover things like this -- "from stem to stern" they said. "Anything that goes wrong" they said. Just not "pre-existing conditions". Oops. Now they tell me that after 3+ years! I'm the wrong person to talk to about the perceived value of warranties -- to me, they're utterly worthless. And if you ask most people who've had any kind of insurance policy on things that failed and then their "warranty" denied coverage (esp. health care plans!) they'll say the same thing. I put zero faith in warranties. It's easier to get things "fixed" by filing a dispute with your charge card company than to deal with warranties! Thankfully, most companies are easier to manipulate via social media than the useless warranties they offer.

You're welcome to spend your time however you want. Just like some people love to constantly tinker on their own cars, and won't own anything built after 1990. That's perfectsly fine! I'm just as uninterested in futzing with my car as I am with constantly futzing with my OS and computer hardwere. There was a time when I totally LOVED futzing with the OS and hardware. Today I just want it to run. Apple's OS is basically Unix, and I can get at it via the Terminal app any time I want; I do that very rarely any more. It's not about the cost to me, but how little I have to actually think about it and am forced to deal with it. Some people prefer to clean their own homes, and some prefer to have someone clean it for them. Arguments can be made on both sides. But saying you do your own cleaning just because you think "the cost [to have someone else do it] is outrageous", then it's not about the cleaning any more, is it? Neither one is "right" or "better". I just find that Apple's ecosystem takes far less of my time and attention to maintain than Windows. That's priceless to me. YMMV.

I didn't realize this forum caters to "average consmers".