Joseph MItzen

That depends on the database and the version. For instance, in PostgreSQL < 9.2, a count(*) query would have to perform a sequential scan through the database: MS SQL Server, and now PostgreSQL, can often do index-only scans in situations like this, for much quicker results.

They're modern classes in essentially every way except inheritance. I imagine they did this to get around the memory management issues with the standard classes. Heck, even Niklaus Wirth in the past has suggested that objects are just Pascal records with methods. 🙂

But what happens now that Embarcadero has been turning records into classes?

If it's not ready, you don't ship it. It's that simple. Either the quality comes first or the release date does. Nick Hodges got fired his first time at EMBT because of his comments to the team about management's willingness to ship a bad product, stating in an email to be careful about quality because EMBT will ship ****. In the end, Marco went along with the release, so he owns it as much as anyone else.

When did they hire a Java developer to name things?

Honestly, if I ran the idea of paying $149 to be able to display an SVG file to any programming forum outside of this one, I guarantee you the reaction would not be positive. I've always said, "Make money with Delphi, not from Delphi". A survey of developers found that the number one reason they gave for choosing a language for a project was the number of libraries available for it (and preferably open source ones). When the Delphi community tries to charge for things that are free everywhere else, it just makes it that much less likely that someone will choose Delphi in the future. The barrier to entry is raised that much higher.

And yet, that's the way the software world has headed towards. Open source is more than just good for "social collaboration", it's good for producing secure, reliable code at a potential pace that far outstrips what any commercial vendor can produce (e.g. the Linux kernel has more contributors than even Microsoft can devote to its own kernel).

Damn, even floating points have to wear masks right now.

UTF8 doesn't need a BOM regardless of encoding.

BOM is both not required by the UTF8 standard and discouraged. Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature

I thought it was only Windows programs that ever put the BOM in in the first place. At least in the Linux development community they tend to consider it a Windows thing. Wikipedia says... So basically no one should be expecting a BOM in a UTF-8 file (and it's not required) so I don't believe you'd run into problems omitting it.

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,