Mason Wheeler's thoughts on Delphi programming in general, and particularly on the technical aspects of developing the TURBU engine and editor.
Archive for the ‘Delphi’ Category.
I’ve been playing around with DeHL a lot lately. Embarcadero’s own Alex Ciobanu wrote this library, which provides a lot of useful functionality, including a set of querying methods that, while a bit bulky, are probably the best we’re gonna get until the compiler team gets around to implementing LINQ as a language feature. (Which I really hope they will do.) Continue reading ‘RTTI errors and omissions in Delphi XE’ »
I liked Delphi XE when I tried it out, but I still haven’t really moved all my work over to it. It takes a lot of setup to migrate everything, and I’ve been busy with other stuff lately. So I was doing come coding in D2010 last night, and I ran into an annoying error. Here’s a simplified version. This really ought to compile, but the compiler choked on it.
Continue reading ‘A pleasant surprise with Delphi XE’ »
This week’s just getting started, and it’s already had more than enough awesomeness to pack into a typical month. The new version of Delphi came out yesterday. Metroid: Other M and The Way of Kings, a new Brandon Sanderson book, were both released today. (I have a feeling I’m going to be more distracted than usual for a while…) But as awesome as Metroid games and anything by Sanderson tend to be, (if you’re into fantasy at all, check out Elantris and Mistborn and prepare to be blown away,) this is a programming blog, and I’m supposed to be talking about Delphi. So here’s the good, the bad, and the annoying about my first impressions with Delphi XE.
Last night at DelphiLive they had a “Meet the team” event in one of the halls, where most of the RAD Studio development team was present and the attendees could hang out and chat with them. While I was there, I talked with Mike Rozlog a bit. He’d seen some of the critical things I wrote on here and on the forums about the roadmap, and he explained to me a bit about how the process of making a roadmap works. One thing to keep in mind is that he told me it’s like this everywhere he’s worked. What I’m about to describe is apparently not a symptom of dysfunctional corporate culture at Embarcadero; more like dysfunctional corporate culture in general. Continue reading ‘The insanities of roadmap publishing’ »
I just attended the Delphi Live keynote address by several members of the Embarcadero team. They used the term “RAD Studio XE launch” a few times, but it’s not available for sale just yet, and they didn’t announce a release date. But the feeling was that it’ll be for sale very soon, within a week or two. I saw a few people filming it, including Jim McKeeth, who put videos of a few sessions from last year up on his blog, so we’ll probably end up seeing it on Delphi.org soon enough. But I’ll recount a few of the highlights here. Continue reading ‘Delphi Live: RAD Studio XE launch’ »
What with recent events and all, it doesn’t look like Nick Hodges is going to get around to finishing up his Pretty Good Practices series anytime soon. So I hope he doesn’t mind if I post one of my own.
Code Review is a very useful principle for keeping bugs out of the codebase. At work we’ve got a rule which is (usually) followed pretty strictly: Any non-trivial change that might affect functionality needs to be reviewed by another developer before checkin. Usually this is just a “rubber stamp” sort of thing. You pull up a diff view against the source control version in Beyond Compare and show the other guy what you changed, he says “OK, looks good, go ahead and check it in,” and you go ahead and check it in. But every once in a while they’ll catch something. Continue reading ‘Code Review: a “pretty good practice”’ »
The second sneak preview is out now. It’s quite a bit more interesting than the first one. FinalBuilder being added to the package will make it a lot easier for me to get builds set up for the TURBU project. Right now I have to do it all by hand. So far I haven’t missed a step and ended up releasing it, but if there’s a way to reduce the chance of that happening in the future I’d definitely appreciate it. I just wonder if it’ll be in all editions or just the higher-level SKUs.
Then they mentioned AQTime, which looked interesting but IMO brings up more questions than it answers. For example, “Since this is the standard edition, not all of the profilers are enabled.” (9:13) But I don’t see any of the profilers on that list grayed out. And again, will this be in all editions, or just the high-level ones?
Also, will it come with an extension to the Open Tools API to allow other profilers to be integrated? AQTime has some great features, but its core feature, performance profiling, uses instrumenting that slows your app down horribly, which makes it unsuitable for a lot of uses. I prefer Sampling Profiler, which gives a good picture of what you’re spending your time doing without instrumenting your program. It doesn’t provide the perfect counting accuracy that instrumenting does, but most of the time you don’t actually need that anyway in order to track down performance problems. If there was a way to integrate Sampling Profiler into Delphi, it would make a good compliment to AQTime’s other profilers.
As for CodeSite, I don’t have too much to say about that, because I don’t know enough about how it works to discuss it very well. Logging’s definitely useful, but usually in different ways than what they were demonstrating on the video. For example, if CodeSite can only output to that popup window, it’s worthless IMO. But if it can write to a file, or better yet if it allows you to create and register custom outputs of some kind, that would be a big help.
The one thing I’m a bit worried about is price. Delphi’s got three general problems, which need to be resolved independently.
Delphi 2011’s main point was supposed to be addressing a missing feature. That ended up not happening, as the team members have been explaining, because they don’t have enough time to get it working at a good quality level. That’s definitely a praiseworthy attitude, but I’m a bit worried at seeing all these expensive third-party tools being suddenly announced as part of the product. They don’t actually do anything to solve the three main problems facing Delphi, and I’m a bit worried that they’ll end up taking the price even higher.
They’ve mentioned their commitment to quality several times, and specifically that they’ve done a lot of work to fix the generics issues. That’s great, and if they’ve allocated some resources to getting a Error Insight and Code Completion working properly that’ll be even better. But even so, not having the main missing feature we were expecting would be delivered is going to do a lot to reduce the perceived quality of the release, even if the objective quality has gone up quite a bit since D2010. Quality improvements are generally expected to be part of an update, not a new release. (The “I paid good money for this with the expectation that the promised features would actually work” argument.)
I really hope I’m interpreting this wrong, but what it looks like to me is that in order to avoid the new version being perceived as “just a bugfix release” that isn’t worth the price, Embarcadero decided to bundle a bunch of expensive tools to make it appear to be more worth the cost. If that’s what they’re doing, there are two ways to do it, and both will hurt them. Either the price stays about the same as it was for D2010, but they’re paying a share of it to the owners of AQTime, FinalBuilder, etc, so they lose a lot of revenue, or they pass that cost along to us, the price goes up, (without delivering the anticipated new feature,) and a lot of people end up not wanting to buy it at that price, so they lose a lot of revenue.
What I would prefer, and what I would do if it was my product, is to negotiate some sort of deal with the creators of these other products where people who buy Delphi XE can pick them up at a discount, and then sell the actual Delphi license to us at a reduced price. That would help improve sales, or at the very least help stem the loss of sales resulting from not having cross-platform available, and no one ends up paying for add-on products they don’t need. (And not everyone will need them. Where I work we’ve got a bunch of developers and one build machine. If we all got a copy of FinalBuilder… what would we do with it?)
I really hope I’m wrong about this, but this is what it looks like Embarcadero is doing. I just wish they wouldn’t, since I don’t think it will actually be good for Delphi users, or for Delphi itself.
Well, Embarcadero has started to release some previews for Delphi 2011 XE, and what’s been released so far doesn’t show any obvious indications that the cross-platform features everyone was expecting will actually be present in this release. Some people on the forums immediately interpreted absence of evidence as evidence of absence and started a big to-do about it.
Continue reading ‘Why the new roadmap won’t impress anyone’ »
Since some version of this question keeps showing up on StackOverflow, and the answer’s always basically the same, I figured I may as well write up a post on here that people can link to. Here’s the question, in simplified form:
“Why can’t I pass a TList<TMyDerivedObject> to a function that’s expecting a TList<TMyBaseObject>? You can pass a TMyDerivedObject to a parameter expecting TMyBaseObject, so why doesn’t it work for lists?”
A couple posts ago, I mentioned that I’ve been working with code generation lately. This is for a part of the TURBU project. An RPG relies pretty heavily on scripting, and RPG Maker, the system I created TURBU to replace, has a fairly extensive, if limited, scripting system. The limitations were one of the things that made me say “I could do better than this,” in fact: No functions, no local variables, callable procedures exist but parameters don’t, so any “passing” has to be done in global variables, only two data types: integer and boolean, no event handlers, minimal looping support, etc.