Joseph MItzen

Nobody bring this up with Rudy. I watched him argue voraciously in the distant past that namespace collision with imported units was a feature of the language and there shouldn't even be a warning because it's a feature. He couldn't recall who called it a feature or why, but that didn't shake his conviction in the least. 😭

In that case, you want to check out goop.

This is why there are embeddable web engines that process Javascript. You need this, for instance, to parse Amazon wish lists, since the pages use javascript to automatically load more items as you scroll down the page. There are also tools such as Selenium for driving web browsers. Or platforms like ScrapingHub, powered by the open source scrapy library and the Splash headless, scriptable javascript-enabled browser

That's a helper method name worthy of Java! Also, what I took from the Woll2Woll article was a bit of a surprise that there's no built-in cross-platform way to send an email with FireMonkey.

It's not so simple in Delphi though.

Thank you; I'm reading this on a Linux box and thought I was missing something for a second. "Write programs to handle text streams, because that is a universal interface." - Peter H. Salus, "A Quarter-Century of Unix" Now, the question is how to handle this with Delphi... Delphi has never gained a simple solution for calling programs and getting the text results back, which is a weird and glaring omission in my mind. FreePascal has a handful of routines for doing so (some of which work across platforms), Qt has QProcess, etc. There's some information here on FreePascal's TProcess: https://wiki.freepascal.org/TProcess and there's a port of TProcess to Delphi (which I haven't tried): https://github.com/z505/TProcess-Delphi Otherwise, you're left with the somewhat complicated default Delphi way of doing this.... https://stackoverflow.com/questions/9119999/getting-output-from-a-shell-dos-app-into-a-delphi-app

Embarcadero can't fire him; Idera purchased EMBT and he was the person Idera picked to oversee Delphi. I'm not sure this was his idea either. I heard it was Michael Swindell who came up with the Delphi Pro EULA change (as well as the bogus 3 million users figure) and he's not only still there, he's listed as "Senior Vice President of Marketing and Product Management". Let's not rule him out as a suspect.

It also doesn't address the fact that Embarcadero service reps are simply outright refusing to do the bumps for those who aren't on current subscription. His "clarification" doesn't address what Embarcadero is actually doing. I'm starting to suspect that this is going to be like the resolution of the Delphi Pro EULA incident, where Embarcadero tried to convince everyone that they never actually made any change. In this case, his clarification is actually a policy reversal and now he's going to tell sales to stop refusing to do the bumps. Then we'll all be told it was never the policy and we just misunderstood. It'll be just like this:

Oh boy, the things I've heard about Packt Publishing. You'd be better off publishing yourself. Their agents work on commission so they'll basically try to talk anyone into writing a book. They'll set impossible deadlines, their editors don't speak English as a first language and will often introduce errors, they ignore the corrections/suggestions of technical editors, etc. They don't do the promotion they promise. And they've been caught before "accidentally" not paying any commission on the book sales generated through a link one could add on one's own blog for readers to buy one's book. I've seen one successful author declare he sold more copies himself than through Packt and when they finally agreed to let him out of his contract due to his allegations they hadn't done what they promised, they still refused to stop selling his book themselves. He then made his book available for free on his webpage to stop them from profiting from his book. It's a horrible, horrible outfit that's little more than a self-publishing firm that takes a large percentage of your sales and does nothing in return.

I asked the Embarcadero IDE team and they said "no". 😈

"...a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort." In theory it would divorce the Delphi language from the Delphi IDE. This would allow for Delphi code completion and other features to be accessed from tools such as VS Code, Eclipse, Sublime Text and anything else implementing the protocol and enable supporting additional languages in the Delphi IDE. In theory. I can't shake the feeling that Embarcadero will find some way to lock things down. But the idea is really great and I've been advocating for this since the concept was first revealed by Microsoft and Red Hat.

Bump Me Delphi One More Time (Sung to the tune of Baby One More Time) Oh Delphi, Delphi Oh Delphi, Delphi Oh Delphi, Delphi how was I supposed to know That something wasn't right here Oh Delphi, Delphi I shouldn't have nuked Windows And now you're out of sight, yeah Show me how to contact Team B Tell me Delphi 'cause I need to use Project Jedi Your installing is killing me (and I) I must confess I need a bump (need a bump) Using EDN I lose my mind I'm in a bind Bump me Delphi one more time Oh Delphi, Delphi The reason I reinstall? The IDE is locked up Oh 'spensive Delphi There's nothing that I wouldn't pay To get out of this cock-up Show me where to send the money Tell me Delphi 'cause I need to compile, all because Your policies are killing me (and I) I must confess I now believe (now believe) Dropping my subscription wasn't fine Here's dollar signs Bump me Delphi one more time Oh Delphi, Delphi Oh Delphi, Delphi Yeah, Oh Delphi, Delphi how was I supposed to know Oh 'spensive Delphi, that Popov needed the dough I must confess, that Oxygene is looking so good now Don't you know I still believe That I'm screwed and how EDN be kind Bump me Popov one more time Your Code Insight is killing me (and I) I must confess I still believe (still believe) One more squiggly line I'll lose my mind VS' looking fine Bump me Delphi one more time I must confess, that your buggy mess is killing me now Don't you know I'm still locked in I see with clarity Can't wait til FPC reaches feature parity Bump me Delphi one last time

No, it hasn't. This is a rhetorical technique invented by Bruce McGee to dismiss any evidence of problems in the Delphi ecosystem. It's also a logical fallacy. Whatever unnamed people may have said about Delphi in another time under different circumstances has no bearing on what actual people are saying about Delphi now under these circumstances. "They laughed at Galileo!" has no bearing on criticism that my new perpetual motion machine can't work. No, it's not "going strong". That's simply factually inaccurate. There exists no quantifiable metric that pegs Delphi as "going strong". On the other hand, every quantifiable metric indicates the opposite. Pascal has long since passed its peak of popularity and it's untenable to argue otherwise. Like Marco Cantu repeatedly stating that he disagrees that the .NET ecosystem is stronger than the Delphi ecosystem, if we don't ever acknowledge the problems we can't find the solutions. Or to quote Saul Alinsky, in order to get to where you're going, you first have to figure out where you are. If Delphi was "going strong", the current owner could just pump $100 million dollars or so into hiring new teams to completely rewrite the desktop compilers, buy JetBrains to get their IDE technology, maybe buy Digia solely to get their engineers' cross-platform GUI expertise, etc. In reality, every realistic conversation about what should be done to Delphi acknowledges they have very limited resources devoted to the product and surely not enough to work on major changes to IDE, compilers and frameworks at the same time. MVP Warren Postma, for instance, has related conversations with the Delphi team in which they privately acknowledged the problems with the IDE parser and that it needs a complete rewrite but management refuses to ok the time to do so. That's the reality we find ourselves in and the reality in which solutions must exist.

I would gladly forego the open sourcing if we could just get such a team now.

Get-It is the official package manager of Delphi and built into the IDE. Torry has been around forever. Scouring all the open source code repositories looking for a needle in a haystack is a serious drain on time. But I believe my point still stands, because according to this analysis of the 100 most popular languages on Github, Delphi ranks 43rd. It's beaten by ... well, almost every language you've ever heard of. All the time. For everything. Just a few weeks ago I saw an example of someone with a bird feeder. He set up a Raspberry Pi with a camera. His program uses OpenCV to detect motion, then it takes a picture. A Tensorflow deep learning network is then shown the picture and asked to identify the species of bird. The Raspberry Pi then logs the species, time, and how long it stays. I thought this was an absolutely awesome idea. I've also seen someone use the Raspberry Pi, a camera and OpenCV to text his friends when free parking spots open up in front of his apartment so they know they can find a place to park if they want to come over. And of course, I'm working on my secret sports betting AI program to win all the money in the world a project I can't talk about. Well, to start, I want my media player to work on desktop Linux, so that rules out Delphi. I know there's a third party option for this, but I also want it to be open source. There have been several media players over the years written in Python, and several popular music fingerprinting and tagging programs such as Musicbrainz Picard. Also podcast management software such as Gpodder. The latter two have made their tag management code and RSS feed code available as separate open source libraries, which means I could use both and get some solid, well-tested code. As mentioned earlier, this leaves me free to write the new features and ideas I have in mind without having to write all the low-level stuff from scratch. As for speed - exactly how fast does a media player need to be? The last time I had media software that was too slow was when I had an AMD K6-III 450MHz CPU and 256MB RAM. My CD-ripping program took longer to encode files than it did to play them, meaning it would have been quicker to record them onto my MP3 player than wait for them to encode!

Oh boy do I have a funny/sad story to tell you. Once upon a time there was certain bug in the Delphi system library regarding regex. Members of the official forum discovered it, diagnosed the cause, and even came up with a small code change that fixed it. Of course, they also created a bug report and included all of this information, including the fix. Several of us grew frustrated that when a bug update or two were released for Delphi this bug still hadn't been fixed (this was back before subscriptions, when you might have to buy a new version to get a bug fix if the short support window ran out before they fixed a bug). Allen Bauer shows up in the forum and some of us ask about this bug. Bauer then requests that we not include any information about what we think might be causing a bug or any possible solutions in the bug report. He says that he wants his newer developers to learn to solve problems on their own and our assistance might also distract them from where a bug really is. We couldn't believe what he was asking. If he wanted to train developers, pair them with a seasoned developer rather than asking us not to try to get bugs fixed as soon as possible! Sigh. I've never in my life seen someone asked to submit less information in a bug report. 😥 So at this point I'm not sure what they might do. When I brought up the fact that the IDE doesn't let you bind your own key choices, David Millington was adamant that I should submit a use case for this "feature". I was incredulous and told him it should be self-obvious why it's a useful feature and how every other IDE in existence lets you do this. He continued to insist that it's always vital to submit a use case. And others could tell you stories of the issues that have been closed as "won't fix" or "by design". I remember Dalija Prasnikar got Marco to re-open several that he'd closed in the past (as far as I know they never actually got fixed though).

Is this the right link? I can't find any mention of Pascal or Delphi in the documentation or the example files.

This is my take on Kylix. Back then, we were all Windows developers and users. What we wanted was a single button in our Windows Delphi IDE that we could press and get a Linux binary/package version of our Windows program. In fact, we just wanted to be able to run headless/server code on Linux. Instead, what we got was a full Linux IDE (actually the Windows IDE using the WINE Windows compatibility layer project, which was in its infancy at the time) that we had to run on a Linux distro and develop with a new framework. I'd tried desktop Linux back then - no support for my sound card, only 2D support for my video card, and it could only read NTFS and Windows couldn't read or write Linux filesystems (still can't). That meant you could move files into Linux, but once they were in Linux, they were staying there. There was little useful software - I remember complaining on the forum of the vendor of the commercial desktop distro I'd purchased that there was no software. They replied "What do you mean? We have over 5000 packages in our repository." Without missing a beat I replied, "Yeah, and 4000 of them are text editors!" (At least that's what it felt like). No one wanted to use shaky distros running a shaky Windows compatibility layer to run a full IDE to redo our old code in CLX. Linux users didn't want it either. At the time, TrollTech owned the Qt technology Borland was using and they didn't have a free license. This made it hard for Linux users to distribute the code - they'd need to bundle a proprietary binary blob with their otherwise open source software.. Borland's answer was to statically link the library, being oblivious to the fact that static linking is absolutely hated in the Linux community. In the end, Linux users were more busy trying to write software for Linux than worry about cross-platform code and they had gcc and c++ and didn't need/want Kylix. Now fast-forward to today. Cross-platform is the new mandate. Stack Overflow's survey says 55% of professional developers are using Linux or OS X to develop on. Linux desktop distros are simple to install and use, useful and very reliable (heck I'm writing this from one right now). Developers want a version of the Delphi IDE they can run on OS X or Linux. Now what are they offered? A Windows-only IDE with a button to push to get a Linux or OS X binary. No UI either on Linux, just headless code. Whomever owns Delphi seems to always "zig" when they should "zag".

I can't believe Idera bought Sencha yet haven't found a way to make Delphi target the browser yet. Even RemObjects (as well as Digia with Qt) have some experimental/alpha code in this direction.

In pure math, yes, but this is memory management, Delphi/FPC is faster just because manual management is way faster than any GC. If you work with large amount of inter-related data objects, Java would not shine as bright, let alone python. The key word here is small. But when Python software grows big, not sure it will happen. Python isn't a weakly typed language. It's a dynamic, strongly typed language. PHP is weakly typed. In Python, 1 + "2" will raise an exception, not evaluate to 3 or "12". As for why it's popular, of course I can only offer a limited perspective. Python does a lot of things well, which helps make it generally useful. It's well-designed with few gotchas (unlike PHP) and easy to read (unlike Perl). It's a very small language with a very large standard library and designed from the beginning to be easy to call out to any language with a C interface. It's very quick to develop in. Someone once said that Python's strength is that it's "the second-best choice for everything". It's gained serious footholds in web development, data analysis, machine learning, penetration testing, devops and system maintenance and control, as a scripting language embedded within other applications, etc. And of course, the massive ecosystem of open source libraries it has amassed is a great strength. It's very popularity is a strength. For example, in my case: my spreadsheet of choice (LibreOffice Calc) can accept code written in Python (there are also third-party libraries that let Excel run Python too). Of the two databases I use, PostgreSQL allows writing procedures in Python (among other languages) and SQLite is included in the Python standard library. My text editor, Kate, uses Python for its plugins (as do others such as Sublime text). My IRC client, and bittorrent client can both be scripted with Python. My ebook management program, calibre, is written in Python and uses Python plugins. My DVCS of choice is Mercurial, which like calibre is written in Python and extendable with it. I jump back and forth right now between data mining suites, but all of them (RapidMiner, Kinime, Orange) can run Python code. My backup software, borgbackup, is written in Python. My mathematics program, Sage, uses Python as its language. My accounting software, GnuCash, has a Python interface. My documentation software, Sphinx, uses Python for plugins. My blogging software, nikola, also uses Python plugins. My media center software, Kodi, uses Python for plugins. Even the shell I use, Xonsh, is based on Python and can run Python from the command line! So you've got a language that's quick to learn, installable anywhere, and you can learn for free, including with free ebooks and courses. And when you do, you find that you can use that language in so many places (per above). I believe that's why everyone, even non-programmers, are choosing to learn Python today. There are so many areas where knowing some Python can save you time and make your work easier. How often would a program need to be freeing objects to make the memory management the bottleneck? More importantly, how much time is that manual memory management costing the developer and how many errors are introduced because of it? As for Python, it uses reference counting with a weak garbage collector that only deals with weak references.

I'm sure you heard about the first ever photo of a black hole. The associated research paper credits the open source scientific python libraries NumPy, SciPy and Pandas. Python was also one of the tools used in the hunt for the Higgs Boson and CERN scientists have spoken at Python conferences. The PyCon conference has been sponsored by everyone from LucasFilm and Disney Studios to Hewlett-Packard, Microsoft, Canonical, Disqus, Mozilla, J.P. Morgan bank, Twitter, Hulu, and Amazon. In fact, those were just a handful of the 2012 sponsors. Take a look at CodeRage sponsors: "Atozed Software, DevJet Software, Fast Reports Inc, Raize Software, Scooter Software, SmartBear and Steema Software." Draw your own conclusions.

That's a major factor that damaged Delphi, per my earlier post. People don't sell each other software libraries anymore. They open source them, which attracts more people to the language, which means more open source libraries for you to use. As I always say, "Make money with Delphi, not from Delphi". Every library that's sold only raises the barrier to entry for a potential new user. If I was being mean, I could say that Python or javascript developers don't need to sell libraries because they can find jobs. Also, their tool suites don't cost more than their desktops. Now your second point gets to one of the things on my list of what I'd do if I ran Embarcadero. You're half right. We need a way to make importing easier. We don't need a conversion tool though. There's a long-running open source project whose software automatically wraps C and C++ code to make it callable from other languages! It's called SWIG, or Simplified Wrapper and Interface Generator. Referencing my point about popularity again, it even supports Modula-3 (!!!) but not Delphi. The good news is that I encountered someone on Stack Overflow whose company added support for Delphi to SWIG internally and were able to generate a fine wrapper of a complex C++ 3D graphics library with it. The bad news is that although asked his company did not appear interested in open sourcing their work. But of course, that means that it is possible to add Delphi support to SWIG. Now, when I tried to broach the subject with The Powers That Be, Marco Cantu decided to deny that a problem even existed, insisting that he does not believe that the .NET ecosystem is larger than the Delphi ecosystem (!!!!). That's when I realized that if you don't acknowledge problems even exist you'll never solve them. Since he wouldn't admit there was a problem, he obviously wasn't interested in hearing my idea for solving it - in this case, I thought Embarcadero should add Delphi support to SWIG and integrate it with the IDE or include it with the installer. Other languages have FFIs (Foreign Function Interfaces) that make it easy to interoperate with other languages. Delphi does almost nothing to make it easier and it's the equivalent of banging on it with a hammer to get C++ code into Delphi. Here's an example of a newer one for Python: PyBind11. (Python has a FFI in its standard library, but it's not very full-featured). But this does serve to illustrate the point that it can be even easier to interface C++ with a dynamically typed language without pointers than it often is to get C++ code working with Delphi currently.

Wait, you thought you knew his project better than he did? Seriously?

As has been established elsewhere, Java is faster than Delphi, particularly with math. It blows Delphi away in SciMark benchmarks. If you were looking for the fastest solution you'd just use C/C++ itself (which is, on average, twice as fast as Delphi code, although David Heffernan has shown examples where it's even worse for Delphi). Meanwhile, it's actually far easier to interface C or C++ with Python than Delphi (particularly object-oriented C++ code) which makes it faster to actually have working code. Developer time is more expensive than CPU time. I've found that jitted Python, in some small benchmark tasks I wrote, tended to match or ever-so-slightly beat FreePascal. Using Cython, which converts Python code to C++ code where possible, could yield results that were just shy of C and far faster than Delphi. Numba, a Python JIT only for mathematics, could also yield double the speed of FreePascal (which is itself often faster than Delphi on mathematical tasks but slower with strings). Numba also has the ability to automatically parallelize operations or even run code via CUDA on a GPU! Another issue is that the Delphi Linux code is slow, and I haven't heard that they've ever fixed this (or acknowledged this). It's about half the speed of equivalent Delphi code, which is itself half the speed of C++. This makes both FreePascal (and even jitted Python!) twice as fast as Delphi on Linux.

Mason Wheeler and I once had an online exchange with Allen Bauer during the end of his tenure with Embarcadero about Delphi and open source, including the chance of open sourcing any part of the toolchain. Suffice it to say that the folks at Embarcadero don't even understand open source much less are feeling ready to embrace it.