Joseph MItzen

This is what they're saying on Reddit too... the software says contact support, and the support team just sends an email back saying to refer to the FAQ which states that support doesn't cover Community Edition. 😞 It's a crazy Catch-22.

So from what I've been hearing, when the year is up the user is going to have to uninstall the old CE, get a new license (if they're still offering it) and then install the new CE and all of their components over again. At least that's what the understanding is without any official comment to the contrary.

Life, the universe, everything... and threads. Lots of things are theoretically possible but incredibly difficult in practice. And should one want to do things the hardest and most error-prone way possible? Professor Lee goes on with a mathematical/logical proof for two pages disagreeing with you on this. 🙂 He goes on about a theory of equivalence for sequential programs, and then... Basically, you can't know that you've written a threaded program whose behavior is deterministic except in the most trivial of cases. The case I cited in my reply to Lars mentioned a project whose purpose was to test using rigorous engineering practices to combat threads and despite code reviews, 100% code coverage, the involvement of concurrency experts, etc. it took four years to turn up a deadlock problem. And that's why threads are evil. Even the SQLite FAQ reads.... I believe this idea is becoming mainstream enough in computer science (if not in application development) that we're seeing the creation of the actor model, the MapReduce algorithm, etc. as ways to implement parallelism more safely. For those interested, I just started reading "Seven Concurrency Models In Seven Weeks: When Threads Unravel" and so far it's a great book. It covers threads and locks, functional programming, separating identity and state, actors, sequential processes, data parallelism, and the lambda architecture. Hee hee, I'll leave you with my favorite quote from Lee's paper then (in jest!)....

I'm not sure I can agree with your optimistic outlook. Threads are inherently nondeterministic in a way that human beings are not. -Edward A. Lee, "The Problem With Threads" It's more like traveling on the back of a hungry crocodile. If I may quote Swizec Teller's discussion of Lee's paper because it sites a perfect example (as well as giving its own car-related analogy): That's not a comforting example, is it? Concurrency tends to cause problems, but threads are a really dangerous practice because of the shared memory issues. Processes, the actor model, functional programming with immutable values - there are a lot of other solutions that are a lot less volatile. As Guido Van Rossum pointed out several years ago, threads were never even originally intended for parallel computation! Unfortunately, a lot of developers continue to equate concurrency with threads. As Mark Summerfield puts it,

But processes can do all those things as well while being much less dangerous.

Is now a good time to bring up that threads are evil? 😈

OK, that is the worst name for a return value I've ever encountered!

Well, again, they're working towards adding other language abilities, so it's not like it's been rejected on design grounds. As for security, some of the languages available with PostgreSQL come in "trusted" and "untrusted" modes. For instance, from the PostgreSQL documentation: And of course any of these other languages will need to be enabled by a system administrator. Regarding "rm -rf" or the like, the PostgreSQL database should be set up to run under its own account with very limited privileges and its own group. In PostgreSQL, only database superusers can create functions with an untrusted language. Now as for performance, there are two points. The first regards performing actions on a large volume of data.It can be far quicker to perform the action on the server, even via Python, than to move the entire body of data to the target machine and perform that action locally. The second is that other languages can allow the end user to easily perform actions that would be incredibly difficult via the inbuilt procedural SQL language, hence it's a performance enhancer. To quote from the anonymous author of "PostgreSQL Vs. MS Server": Python and R have become the dominant languages in data analysis, and machine learning which is why MS SQL Server has added support for them (along with .NET languages). Being able to use a machine learning routine or do logistic regression right on the server inlined with SQL is a really powerful feature.

You really don't want to have an honest discussion, do you? You seemed to come into it with some sort of chip on your shoulder.

Having lots of methods that all do the same thing with a slight twist isn't a good idea. In normal development, you make that one function and supply a parameter. For instance, you don't want one function that returns squares of a number, another for cubes, etc. You have one power function that takes a parameter that raises a number to the specified power. I'm also not clear about the coupling. Classic OOP would, for instance, create a deck of cards class and then inherit from that to produce a blackjack game and a poker class would similarly inherit from the deck class. In the VCL, TJpegImage, TPNGImage, etc. are all inheriting from the TGraphic base class. If they all inherited from the TImage class instead you wouldn't need to do any converting to load and alter an image. In fact, this is how many popular image libraries across languages work. ImageMagick, one of the most popular open source image editing libraries, has a ReadImage method that takes a file name and returns an ImageMagick Image object. One function to load any image type, one object type returned to work with. Pillow is the most popular library in Python. One image type, "image". Further: Same idea as ImageMagick. It's the VCL inheritance scheme that seems rather ad hoc and unusual.

OK, I think I recalled the disagreement somewhat wrong. It was about being able to call a process and get its output back into Delphi. I cited the standard code examples per https://stackoverflow.com/questions/9119999/getting-output-from-a-shell-dos-app-into-a-delphi-app and opined that it was rather complicated. You offered another method and argued that it wasn't really very hard at all.

Why not have just one image type that can read/write multiple formats? Or at least have TJPEGImage, etc. descend from TBitmap rather than TGraphic?

If I understood the original post, what's being talked about is the ability to write procedural code in other languages directly within SQL statements being sent to the server. PostgreSQL offers this, and SQL Server offers this (for .NET languages). For example, in PostgreSQL if Python is installed on the server and the python language support is enabled in the database: jmadden=> CREATE FUNCTION pymax (a integer, b integer) RETURNS integer AS $$ if a > b: return a return b $$ LANGUAGE plpythonu; CREATE FUNCTION jmadden=> select pymax(1, 2); pymax ------- 2 (1 row) Here a user was able to send a function to the server just like a regular SQL statement and then call it. Such code could be in the middle of a batch of SQL statements. Triggers can be coded in other languages, custom aggregates, etc. Firebird doesn't offer this level of support for inlining other languages today.

Do you know what the reason might be for that design decision?

I know David Heffernan and I have debated this before , but IMHO no, there's nothing like Lazarus' TProcess, Qt's QProcess, or Python's run function in Delphi (David disagrees). I also am puzzled why Delphi has never had a simple way to execute commands and retrieve results.