David Schwartz

If that salary is in USD, it's horribly low.

I don't know what PAS 21 might be, but I run VirtualBox on three different Macs, two of which are running 10.14 (Mojave) and one is running 10.15 (Catalina). The VM has Win 10 and Delphi 10.4.2, and it runs just fine. All three machines have at least 16 GB of RAM. How much RAM is in your Mac?

hmmm ... yeah .... you need to type a LOT of stuff that should be available at the click of a button, given a few clues. I discovered there's a function in the JSON library named JsonToObject that I thought initially would read a JSON packet and generate a class then fill it with data. It turns out you need to define a class yourself, then pass it a JSON packet and a class reference; it will read the JSON, create an instance of the class and then fill the fields it finds that match -- which means the fields need to have the same names as in the JSON field names. This is a fair trade-off to me. (The class can have other stuff as well; that method just looks for fields in the JSON file that match in the class definition and copies the values over. I haven't tried using lists or arrays or things like that, so I'm not sure how it handles them, tho.) It should be that easy!

I've decided to just have a callback method at the point where the parameters can be added before calling the API that sends a stringlist with the names of the parameters that particular call can accept (eg, <name>), and it gets back '<name>=<value>' for each <name> in the list. This is as opposed to what I typically see which is a long list of .AddParam( 'somevar', Form1.Edit1.Text ) calls that reach back into the UI unit (eg, Form1) and grab the values from the Date/Edit/Checkbox/Memo fields directly. Why should the API unit have intimate knowledge of what's on a form? As much as people love to talk about the principles of OOP, it baffles me that so many Delphi programmers still seem to toss all of that out the window when it comes to Delphi Forms. It's like, "Oh, Forms ... yeah, they're objects, but ... meh ... it's too much trouble to define properties and DI and stuff. That 'encapsulation' nonsense is for library files, not our own units."

This is a great interview with Anders Hejlsberg done recently. I learned a few things I didn't already know about the history of Delphi and why certain things in the programming world evolved the way they did. Anders has a very unique perspective from working at both Borland and Microsoft for as long as he has. I'm guessing that Anders is a few years younger than me from what he said here, and I can certainly appreciate the value of being able to look back on 40+ years of an industry that you watched get born and grow up.

I've been looking into what it takes to build a cross-platform app that's mainly audio-based. Each platform has its own set of media interfaces and logic, and stuff that works on Windows doesn't translate easily into what any other platform uses. A common framework would help a lot, but it's a lot of work to build and maintain. Someone pointed me at the Web Audio API (WAA) for web browsers; it's a javascript library that's been around now for most of a decade, and it's supported fairly completely by most of the latest browsers. An excellent book was published earlier this year about it that can be found here: https://www.routledge.com/Working-with-the-Web-Audio-API/Reiss/p/book/9781032118673 I'm guessing this is being used in a college course by the professor who wrote it. I ended up getting some help from Andrew Simard who has been writing a series of Application Notes for TMS WebCore that have been posted on their blog. I gave him a couple of suggestions for demo apps which are hardly trivial, and he dug into both the UI side and the logic side, creating a couple of rather amazing demo apps. What's most amazing about them, in my mind, is that they run inside of the browser, and therefore on pretty much any browser and platform that supports WAA. I invite you to take a look at the two articles and see what Andrew was able to accomplish using TMS WebCore on one side to implement a lot of the logic in concert with the WAA library on the other side -- which is all the more amazing since it's all in javascript. The UI side is all in HTML and CSS, written in WebCore / Delphi, and there are numerous events that are generated on the UI side passed back and forth between the Delphi side and the javascript side. The second post has a link to a live example; perhaps Andrew will add a link to the first post as well. Here's the first article: https://www.tmssoftware.com/site/blog.asp?post=999 and here's the second article: https://www.tmssoftware.com/site/blog.asp?post=1003

Hardware encryption needs to operate differently. This makes total sense.

I've worked with a few Samsung T-5 drives and they come with encryption software on them. So do lots of thumb drives I've gotten over the years. The files are usually in a folder and there's a READ.ME file and info about how to use it. I've not seen one that mounts up as two devices, tho. That would always work. I'm curious what devices you're referring to that do that. The encryption would be on the memory device, but the CD device would be unencrypted, but probably flagged as read-only. You should be able to see it but not erase it.

The first thing I do when I get a USB memory device that has encryption software on it is I reformat the entire drive. I've never looked at that stuff, although I did notice an autorun.inf file on one device. I've not noticed any that show up as CD drives, tho. If you say they auto-run, I'll take your word for that. (These things I looked at actually registered with two USB IDs: one was a read-only CD and the other was a r/w memory device. The system would look for the autorun.inf file on the CD partition. I think that's how they did it, but you can't simply partition the drive; the device's logic has to respond as two distinct devices, probably as if they are both connected to a hub. It was 20 years ago and the details are fuzzy.)

It's a convention added to Windows to get CDs to auto-run a setup.exe when you inserted the disc into the drive, as opposed to booting from it. When thumb drives hit the market, you couldn't even boot from them until vendors added that into the BIOS. But it was still problematic to make them auto-run something when you plugged them in. Some vendors added a setting into the BIOS to enable that, because it's a big effing security risk. Why run anti-virus stuff if someone could simply pop a thumb drive into a USB port and have it inject something into the computer without ever displaying something on the screen or tripping the anti-virus stuff? USB ports are (were) problematic for AV scanners because they had to figure out what type of device was connected, if it had any storage, if it made sense to scan it ... how does a memory device differ from a LAN adapter or a WiFI adapter or a serial port? At least CD readers don't change their character, but USB ports do.

There was a time where I did C++ almost exclusively for about 10 years, then Delphi came along and I transitioned over to it instead. I played with CPPBuilder a few times and found it far more verbose than Object Pascal, although I think, generally speaking, OP is more verbose than C++. It was the way the VCL was set up and accessed through C++; it just struck me as extremely convoluted. I've hardly looked at C++ in 15 years, and recently looked over the latest C++ standard ... boy oh boy ... they have added so much "bling" to the language that it's nearly impossible to read the code! It looks twice as verbose now as before! There was a lot of stuff that you had to learn that was idiomatic; today, so much of that has been made explicit through "attributes" and callouts of library options and so much gnarly stuff. I wonder if code from 1995 will even compile and run today? I know Delphi1 code probably will. Anyway, I'm thinking you might be a lot better off translating those C++ units into Object Pascal, mainly because you wouldn't be stuck trying to find someone to bridge these two langauges even though they're still more-or-less integrated into the same IDE. I'm not aware of anything that can be done in C++ that can't be done in OP.

This was a holdover from CD-ROMs. It's actually a really hairy securitiy risk. You had to go into the ROM-BIOS of the machine and enable a setting to run it, but I'm not sure that even exists any more. At one point, I was looking at something that did that predictably and found a company in Japan or S. Korea that made thumb drives that registered themselves with Windows as CD-ROM drives, thereby enabling the autorun.inf to be called. I got some demo devices for testing and they worked as advertised, but that project ended up not proceeding. A year or so later I happened to check back with the company and they were no longer selling those devices. I've been in many places where their IT Dept literally disables the ability to mount any sort of external memory device via USB to their computers. That does not keep you from transferring files, it just makes it a bit more convoluted. (This is where being a Windows programmer comes in handy!)

I'd suggest you start out building something simple. Building something that can be wrapped in Miletus is probably the most complex thing you can start with. It's like someone says, "I want to learn Delphi; I'm having trouble getting the web service to work on a Linux server that my app needs to run." They have a support forum that you should be able to join and post questions. Also, check their blog for examples.

I was diagnosed with Asperger's last year and it explains a whole lot of strange things going back to childhood. One is that I tend to be very wordy. I cannot comprehend how folks can say anything useful in ten words or less. For most of my life, I just avoided saying much because I'd get so much crap for it. But since being diagnosed, I've come to embrace it. Yes, there will always be people who get annoyed. I envy them for their ability to be brief. A common complaint I've heard over the years is something including the words "over-analyzing" or "over-thinking" things. Asperger's is said to be a form of autism, and one thing that characterizes the autistic brain is we tend to be dealing with 10x or more stimuli coming into our brain at any given moment that most other folks. Here's an analogy: In baseball, you can be standing at the plate, and for most people at bat, they just see the pitcher, the wind-up, and then a ball coming at them. They can focus in and just see the ball. And they have to make a decision when the ball is about 1/4 of the way towards them whether to swing at it or not. I see the ball, the pitcher, the second baseman slapping his glove, the short-stop stepping sideways, the left and right fielders getting ready, the 3rd-baseman, the 3rd-base coach signaling the guy on 2nd base, the birds flying at the lights, some people in the stands jumping around and waving, and I hear all of the noises behind me and coming from the dugouts. Sometimes it's a wonder I can even swing the bat before the ball is in the catcher's mitt. I loved basball as a kid; I played left field, and I could stop anything coming at me. But I could never hit the ball worth a darn, so the coach would only put me in on the 7th inning. When I hear those words, "over-analysing" and "over-thinking", it reminds me that most people have brains that allow them to just focus on the pitcher and the ball, without all of that other crap distracting them. For THEM, they'd have to think long and hard to be present to even a fraction of the "noise" that floods into my head every waking moment of my life. For THEM, it WOULD take a LOT of analysis and thought! For me, it's just what's there when I look at ANYTHING. It's like ... human beings have a "squelch" control in our brains that's set to only allow the strongest and most intense signals come through to our brains. But people on the autism spectrum have that squelch control turned down so we get a lot more noise along with the signals we're looking for. And we have to process all of that crap in real-time just to stay focused on whatever it is we're trying to deal with. People on the so-called "lower-functioning" end of the spectrum have it turned WAY down, to the point where they can't talk or control their muscles well due to the constant overload of signals coming into their brain. At least, that's one of the latest theories. It seems to capture some of the dynamics involved, anyway. It's a big plus in the software field because it helps me be a great architect -- I naturally see things from a birds-eye view, and often with far more breadth, depth, and detail than most other folks. Of course, they all think I'm off my rocker and say things like, "Earth to Schwartz ... come on back to the meeting!" I cannot tell you how many problems I've seen over the years that nobody wanted to talk about that later on came back to cause major problems. It's both a gift and a curse. It's just how my brain works.

Since 1999, I've been hired numerous times because I'm an "expert" with DELPHI -- not merely with Pascal. I have never been asked about either FPC nor Lazarus for use in any sort of production capacity. They have language features that Delphi only dreams about, and they can be fun to play with. Even an educational institution I worked at for nearly 5 years kept their Delphi license current and the project head refused to even consider FPC or Lazarus. Lately I've been shifting my focus over to TMS WebCore because I believe the future lies in web apps for generalized cross-platform needs, rather than a hodge-podge of separate platforms that are all evolving so fast that keeping track of them all in parallel with moving the common platform forward is an expensive exercise in chasing one's tail just to stay current. TMS has also added the ability to encapsulate WebCore (or any web-based) apps to run as native apps using their Miletus technology. Is this a panacea for all of the humonguous apps historically built with Delphi that have been around for more than a decade? Hardly. But the last three jobs I've had all implemented a ton of stuff in core parts of their systems that could be moved without too much trouble into service-based instances running inside their own network. One was slowly moving in that direction for newer things, but I saw a ton of resistance elsewhere. An earlier one was migrated from one DB to another. I know we could have done it in-house in about 4 months, but upper Management insisted they thought it would be better to outsource it. I have no idea what it cost, but probably over $500k, and it ran over by 50% before they pulled the plug and the other dev on our team finished it up in a few weeks. The whole thing could have been reimplemented in far less time as a REST-based service, but everybody thought that was just way too risky and that the performance would be really bad. They were just guessing, of course. The bottom-line is ... Management sticks with what they know. From what I've seen in most apps I've supported, there's a ton of stuff that can be easily factored-out and moved into REST-based services. There's also a lot of UI redesign that can be done to simplify different use-cases. What happens with these big desktop apps is they start out simple, then get warts added on top of warts until you have this huge, complex mess that's got all sorts of right-click options on virtually everything to deal with common needs that cannot be provided without severe change to the UI. Moving these horribly mutated ginormous desktop apps over to web apps without significant redesign is silly. But it's all that companies seem to think is warranted. Either that or it's like: "well, if we're going to rebuild it, there's no way in hell we'll use Delphi! We'd only consider C#/.NET in that case." I have personally never seen a single one of such redesigns ever completed on-time or within budget. So I'm not doing Delphi work any more, because pretty much the only jobs I get hired for are maintaining ancient legacy Delphi apps where the company generally refuses to allow us "experts" to do any sort of refactoring. (I have always suspected that's because they usually have no automated test suites.) I honestly don't even know why they bother to hire Delphi "experts" because they never wanted to hear anything I suggested. My job was to simply fix bugs reported by customers and add the occasional feature that a customer pestered them to add -- and often paid for. All that to say, I don't think this has anything to do with "Pascal" at all. They know "Delphi", not "pascal". But if they were to switch, they'd rather switch to JavaScript, Python, Rust, and Go. Even C# is fading away.

At some point, I plan to hire a seasoned Delphi dev for a project. It involves building a web-app using TMS WebCore and a back-end service to support it. There will be three parts: the client-side logic, client-side UI, and back-end services that will use several TMS Biz libs. Learning to work with WebCore for the logic part is not a major conceptual jump for most Delphi devs, as well as basic (out-of-the-box) UI design. As for the client-side UI part, WebCore has its own components and you can also use the TMS FNC components for the UI widgets, as opposed to VCL or FMX widgets. I find them easy to work with using the default settings. However, they can be tweaked using javascript and HTML. WebCore also lets you import most any javascript library, including GUI libs, and I'm planning to use a couple of non-GUI js libs so far on the client side. I'm far from a js expert, and some of these libraries make my head spin. So I'm wondering if I should also plan to hire someone who's got experience working with a variety of javascript libraries (particularly the ones I'm considering using), and expect them to learn enough Delphi to work in the IDE (either Delphi or VS Code) to help with all of the client-side javascript integration? I'm sure this situation is not unique to Delphi and how TMS WebCore work. So I'm curious how others have made this sort of tech mash-up actually work in a real project environment? The client-side logic could be done in C# with UI libs in the MS variant of javascript. The same issues will arise, right? Would you hire an experienced JS dev? Or just have the Delphi/C#/etc dev learn enough JS to make it work?

errr ... WebCore runs pas2js and translates the Delphi code into js. The "clever" part is being able to code in Delphi, not the fact that the runtime is 100% js and it can work with virtually any existing js lib you can find. What I need is someone to write a couple of classes for me in js that use another js lib, and then I want to access that lib from the Delphi language side as PODOs. The underlying library I need to use has some functions that use multi-threading to do things. I've been trying to do the multi-threading at the Delphi level, and it's just gnarly. I'd rather have a couple of classes to abstract out what I need at the Delphi level, and just let them manage things natively at the js level. There are already a bunch of popular js libs imported into the framework that can be accessed on the Delphi side. That's how things work if you want to extend WebCore the same as adding components and libs to normal Delphi.

have you considered making a helper method? Or a subclass? It really doesn't matter all that much, but they should be set together, not separately, IMHO

It's a web app, written in Delphi using TMS WebCore. I can do that myself, but I'd rather hire someone to do it. You asked "why Delphi"? This whole project is like mixing oil and vinegar. I know Delphi and I know WebCore -- the "oil" part. What I don't know much about is the javascript and HTML that controls the UI in the DOM -- the "vinegar" part. I'm also at a point where I want to stop doing everything myself and coordinate a team that's doing the work. I can hire a Delphi dev, or do the Delphi part myself. Either way, the Delphi part is not the problem I'm facing. WebCore uses pas2js to translate Delphi into javascript and it packages it up so it runs inside of the web browser. This opens it up to the ability to interface with other JS libs and functions wrapped up in a way that they look and act like plain old Delphi objects. As it happens, there are a bunch of properties in both the WebCore and FNC UI components that let you insert HTML tags to fiddle with things inside the DOM. I don't have a good understand of that side of things, and I'm not sure how many Delphi devs do either. But folks who work with JS know this stuff cold. I don't need help with the Delphi part. What I need help with is the javascript stuff, and someone who's adept at those HTML tags that need to be set in the UI components to fiddle with things in the DOM. It would be nice if I can find a Delphi dev who understands WebCore enough to make sense of this. But the javascript part is still way off in the weeds for me. The JS person doesn't need to really know much about Delphi other than how to set and edit those HTML tags in the IDE's property editor. THAT is something that can be learned in two minutes as it's not unique to Delphi's IDE. All that said, have you ever sifted through a pile of resumes for Delphi devs looking for people who can do low-level and back-end stuff, and you get a bunch of "form jockeys" whose entire Delphi experience is making hundreds of forms by dragging-and-dropping the fields from the little box that appears when you double-click a TDataset in the IDE, onto a form, and then moving the fields and captions around so they look nice? That's what I'm getting as far as people who claim to know UI programming with javascript. I don't know much about js, but these people who are looking at my job posts can't even ask intelligent questions about my stated requirements. Would I be better off just having the Delphi person learn javascript and slog through figuring out the JS side of things?

This really isn't about Delphi. WebCore is easy to work with and is quite adaptable to JS widgets and frameworks. I don't think that using something else to build the UI part isn't going to save me much time. That said, given a moderately complex mobile front-end (UI) app design, do you think it would be quicker in Delphi + WebCore; JS + some IDE; or something else entirely? What I'm having trouble with is finding someone who knows javascript for more than simple UI interactions and can build a non-UI library on top of another JS API lib that I need to use. THAT library they create can (supposedly) be integrated into WebCore fairly easily. It can also be accessed through HTML5 tags with appropriate parameters -- these are simply properties in the IDE that can be edited through a string property editor. The only Deplhi someone needs to know is about as complicated as figuring out how to edit similar properties in Photoshop and other IDE-based tools.

Maybe you'd want to look into WebCore before summarily dismissing it. When you click F9, it translates Delphi into javascript and generates a web app that then runs inside the web browser and can be debugged inside the IDE. The devs went so far as to make it easy to integrate existing JS libs (both non-visual and visual) into the mix so you can work with what's already out there to create and access functions that live inside of the browser -- which, BTW, Delphi cannot do by itself. (Browsers don't know Object Pascal.) You'd have a far better chance of getting hired if you actually looked at the technology in question and posted a more encouraging reply. But saying it's a dumb idea without knowing what it is, and that you're the only person I might find to do this work, isn't going to get you anywhere.

Yes, I think they should be set together to ensure contextual integrity. Eg, a TSplitter.Constructor that takes the two splitters as parameters then sets their siblings appropriately.

Jeez ... has it been 10 months already? OMG! There's an idea that came to me in 1995 that was not technically feasible until 2015, but it was missing a couple of key pieces. The last piece was out of reach until this past February. My challenge for the past 18 months or so has been getting the needed funding and pulling together a team to build it. I have not succeeded yet. A lot of startups are created by a bunch of friends who either live at home or work together and spend their free time on it, so they don't need much capital. Once they have an MVP, they can get funding. Steve Jobs famously said about the iPad (that was almost universally panned by every corner of the tech world): "Sometimes people don't know what they want until you show it to them." The iPad created an entirely new hardware segment: the "tablet computer". What all the pundits seem to have missed was that it was hardly a "new concept". Every Star Trek fan has been seeing them in the hands of every version of that show since it launched. We've simply been waiting for one to appear in real life, and Jobs finally did that. That's what I've got: something nobody understands and doesn't know they want. So my plan is to build it, then put it into the hands of ~40 people who all have at least 1000 raving fans they can encourage to try it out. The capital raising hasn't been fun. I'm mostly looking forward to building a team and then getting this idea out of my head and into the world. THAT WILL BE A LOT OF FUN! In case anybody is curious, I plan to use Delphi with TMS WebCore to buidl a web app, and then maybe create native apps using their Miletus technology.

Check out TMS Software. They built an RPi app over Christmas and made an extensive case study of it. https://www.tmssoftware.com/site/blog.asp?post=872

I know, it's very odd to me as well. When I graduated from college I got hired by Intel. They tended to hire EEs; my degree was in math / computer science. Everything I worked with there was proprietary. I got caught up in their first layoff 5-1/2 years later. Looking for what was next, people kept telling me, "Well, you've got a CS degree ... you can learn anything pretty quickly, right?" I ended up getting hired at a Motorola division and they wanted me to learn C and Unix. C++ was just coming to the fore as well. After the world didn't come to an end on Jan 1, 2000 (Y2K) the market was flooded with about one million excess programmers, most of whom were here on H-1B visas. That changed the entire complexion of hiring practices across the software and IT industry. Jobs that used to get 5-10 job applicants were now getting hundreds. Executive Recruiters who used to have the ear of hiring managers disappeared, and everything was moved to automated systems. Job descriptions became more standardized and HR people didn't really have any clue what any given job entailed. People learned they could "keyword stuff" their resumes to improve their chances of getting a call-back, if not an interview, whether they knew what the jobs were or not. Things have devolved to the point where it hardly matters what your educational background is -- if you don't have 3-5 years immediate experience with whatever platform or stack a project is using, they won't consider you. Nobody wants to pay for on-the-job training any more. I was at the event when Delphi was announced in 1995 and got a free copy of it. I started playing with it and was quite amazed. Unlike VB, you could build Delphi extensions (components) in Delphi itself, you didn't need to use another language. And unlike VB and other things where all "extensions" were DLLs, Delphi's components could be linked into the EXE as normal library code, so there was no run-time penalty to use them. Over the next 5 years, I switched my focus from C++ to Delphi, mainly because Delphi was so much easier to work with, especially for UI-based apps. Since 2005, I've had a bunch of different roles that I got mainly because of my Delphi expertise. Every one of them had fairly complex systems that took many months to learn and were in application domains that were new to me and had very little in common other than they were all built in Delphi. Most of them were, in the words of one colleague, "keeping a comatose patient alive until the new system was built", usually that meant "porting" it over to C#/.NET. I never saw any of those "ports" get completed. The last place I was at, I kept hearing people at all levels of the organization say things like, "Well, you're the Delphi expert, so you understand how all of this stuff works, right?" (IOW, since I knew Windows, I obviously must also know how ALL Windows apps work.) This was an incredibly complex system and it took most of a year to start making sense to me. A guy they hired 8 months after I'd started didn't know much about Delphi but had 10 years of app domain experience, and he was able to come up to speed much faster than I did because of his extensive domain expertise. I discovered that the entire (Delphi) dev team quit in 2011, although very little had changed since 2009. My first day on the job I was told, "Do not touch ANY of the code!" It has always struck me as odd that hiring managers seem to think there's more relevance in knowing a given programming language / platform versus an application domain. The app domains are usually far more complicated and take a lot longer to learn than a new programming language / platform. I mean ... at some point programming is programming. Every imperative programming language is pretty much the same, and they all tend to have the same structure, so learning one more isn't a big deal. (Actually, they're all easy to read; writing new code takes a little more time.) I'm semi-retired now so I don't have to deal with this crap any more. I can do what I want with my time now.