Categories
Audio podCast podcast

44 – Allen Bauer – Part 1 of 2

Sitting down to talk with Allen Bauer, Chief Scientist at Embarcadero working on Delphi.  Talking with Allen about Delphi for Mac, 64-Bit Delphi and Delphi on other platforms.  This is part 1 of 2.

Standard Podcast [ 1:02:22 ] Play Now | Play in Popup | Download

29 replies on “44 – Allen Bauer – Part 1 of 2”

Hi Jim. Nick also had a part1 hope we here the part 2 from Allan 😛

Mason,
“absolute” can cause significant type-safety holes by allowing one to “overlay” a variable of one type on top of a variable of another type. In the future this will cause significant confusion for things like further enhanced meta-data and run-time stack information leading up to a richer/safer run-time experience. This would certainly interfere with the potential future inclusion of garbage collector, for instance.

@Allen:

By that argument, variant records, pointers and hard-casts are also “holding the language back”.

If you want garbage collection and other pseudo-productivity features embedded in your language then you have the choice of using a language that offers such things.

imho Delphi will thrive not by playing “me too” and “feature catch-up” with those other languages (the mistake that Delphi.NET made and a role now fulfilled by Prism) but by offering the alternative … power and flexibility, yes perhaps at the cost of not having some sexy new features that your compiler developers might like to have fun trying to implement.

Jolyon,
How you doin’? Good to see you here. In general, I agree. Delphi needs to no only offer “modern” language features and concepts, but it also needs to find ways of blending the old with the new. However, there are cases where certain features *do* run counter to our goals. Specifically for “absolute”, how it is implemented and expected to work does cause some limitations on our ability to progress things. For the other things you mention, we are looking very hard at maintaining those in one way or another. Specifically, variant records could be done by adding hidden metadata tag information that would describe which branch of the variant is active. The other items, such as pointers and hard casts, could also be handled by relegating them to specific compiler modes that require one to “opt-in” in order to use them.

This is by no means an exhaustive list. I was merely highlighting one relatively obscure item as an example. I do realize that it is only “obscure” if you rarely if ever use it. Otherwise it is not really “obscure” for the person relying on it.

Great interview. Didn’t understand 90% of it but nodded vigorously at the bit about compiling existing code with very few changes.

I will hopefully understand more of Part 2, particularly if it contains the phrase “you can just recompile existing code and sell it to Mac users”.

@Allen, Moritz: Fair enough, but I’ve always thought of absolute and hard casts as a way to tell the compiler “Trust me, I know what I’m doing. You don’t have to worry about ensuring type safety here because I’ve got it covered.” They don’t violate type safety so much as shift the responsibility from it from the compiler to the coder. (Who is then free to violate type safety to his heart’s content, of course.)

I can’t comment on the rich metadata Allen had in mind, but with regard to the garbage collector it basically gets down to the question whether Delphi will be able to employ an exact GC or whether it has to stick with a conservative GC. A conservative GC is just as the name implies – in fact it’s so conservative that you can use it with existing Delphi and C++ code without any changes (assuming you don’t bit-twist your pointers, stuff them in unaligned memory, hide them in external resources or pursue other pathological abuses). But the downsides of the conservative approach degrade the GC to a mere performance optimization. It can’t move around memory to overcome fragmentation, it needs to scan the entire process memory upon collection and it is prone to systematic memory leakage, other than an exact GC which only exhibits “logical leaks” (which you have to deal with in non-GC environments as well).

Personally, I can’t quite imagine the traditional Delphi to completely rule out type-unsafe operations at this point. (After all, every kind of inline assembly code is inherently type-unsafe, but still the team goes to great lengths to make sure BASM is available in the 64-bit compiler.) I’d rather expect the type safety question and the GC to be more relevant in the “other platforms” Allen is talking about.

Of course the compiler could go with an exact GC and still permit you to hard-cast if you think you know better. But when looking through my own everyday uses of unsafe code, I noticed that most of them have to do with storing a pointer in a weakly-typed manner (object ref -> TComponent.Tag, ref -> LPARAM, ref -> untyped Pointer). So (if you excuse this generalization of my observations), given that pretty much all of my type-unsafe code is going to break anyway with an exact GC, there’s not much point in allowing it to compile.

@Mason: That’s very well put.

Managed code on the other hand typically comes from a place of “The developer never knows better than the compiler”

@Allen: What I can’t quite put my finger on is why additional meta data could not also be put on “absolute” in the way that you seem to envisage for hard-casts.

As I observe in my blog post, an absolute variable is effectively short-hand for repeated inline hard-casts.

The compiler can surely treat a variable declared “absolute” as an inline hard-cast “macro” (maybe not literally, but in effect) and whatever safety mechanisms you envisaged for hard-casts could then be deployed for references to “absolute” variables.

Or just make it an “opt-in” language feature, as you suggest. 🙂

Hi Allen,

many thanks for the great interview.

You mentioned that the length of a string will remain at 32 bit. Instead people can use an an array.
But what about the TStringBuilder? It wraps a TCharArray and with it it also shouldn’t be limited to 32 bit. Since the TStringBuilder has advantages according the allocation of memory it is IMO already the recommended data type for string manipulating.

—
Thanks,

Roman

incidentally my VERY FIRST Delphi program (Delphi 1) was a fake error message where the OK button would run away from the cursor (swapping sides with Cancel)

As regards linking 32 bit modules into 64 bit apps…. I actually do have a way of doing that I use already…. but that’s handled by my Lua4Delphi system… it can also do the reverse… linking 64 bit modules into 32 bit apps.

Jolyon wrote :
Managed code on the other hand typically comes from a place of “The developer never knows better than the compiler”

I don’t think Delphi should ever be made into “managed code” – look at what it’s done for .NET 😯 😳 😉

Jolyon wrote :
Managed code on the other hand typically comes from a place of “The developer never knows better than the compiler”

I’d say 99.9% of the time the developer doesn’t know better than the compiler. Also, funnily enough, 99.9% of the time the developer THINKS he knows better than the compiler!

Jim and Allen, thanks for this very informative interview. Already waiting for part 2.

Excellent interview- informative and entertaining.
Looking forward to part 2.

I need part 2!!!
Hey, I would like to see on the next rev. of delphi
1) Voice to text (or commands)
2) Text to speech
3) saving .wav file from Mediaplayer takes too much disk space. The Mediaplayer should be able to save to a mp3 (MP4) format.
4) interface(links) to kinect box.

@Troy,
Couple of things:
1 & 2) I’m already working on a SAPI 5.4 (Vista/7) translation and component suite for TTS and Voice Recognition systems… SAPI 5.1 (Windows XP) components have existed for years and work fine on XP.

3) There are PLENTY of components out there already to facilitate conversion of WAV to MP3, or even direct TStream encoding (save strait to MP3 or any other format of choice)

4) http://www.lakraven.com/delphi-stuff/tkinect/ < Interface(link) to the Kinect controller… made by me! Been out more than a month… have you been hiding in a cave? 😉

Note that my last comment really is meant in good humor!

Restrict string type to be 2gb in length is a mistake. All dynamic types must be treated the same in term of size in bytes. They can not be lazy that not fixing all codes that is I := SizeOf … or I := Length… without changing the type I from Integer to NativeInt/NativeUInt

While Allan was talking about int, LONG, LONGLONG, and other types, I was thinking : Why don’t we just forget all that and start using Int8, Int16, Int32, Int64 (perhaps even Int128) and their unsigned counterparts (UInt8, etc)? The same could be done for floats : Float16, Float32, Float48, Float64, ect…
Sure, we cannot really forget the ‘old’ types, but at least having a clear collection of base types should help in declaring the OS native types. Right now we have to do this kinda backwards – we have to define these types by aliassing native types, but really : Shouldn’t this be the other way around?! (Especially with an eye on a single rooted type-system.)

And while Allan was talking about string types, it triggered another idea I have been pondering for a while now : Currently we have classes, object types, records and interfaces; Each offers a few aspects (like the availability of a VMT, the ability to overload methods, heap- or stack-based allocation, automatic reference counting, ect.) but we cannot mix-and-match these yet : Wouldn’t it be cool if we could declare an interface without reference-counting? Or a (stack allocated) object-type with a VMT, allowing calls to overloaded methods? Or add an interface to a record type? In a way, I think we should not view them as separate entities anymore, but more as specific combinations of techniques. Giving the developer freedom in combining these would give us a more powerfull language.

Oh, one thing I was missing in the interview, was performance implications – how does the generated 64 bit code compare against benchmarks written in other languages, compiled with various compilers? In my experience, 32 bit Delphi is not all that good in optimizing code (I often see inefficient assembly code being generated) – so I hope the new 64 bit backend will not make things even worse…

Simon,

Thank you for your help!!
I did see the Kinect controller a few weeks ago, That is tooo cool!!
I was Hoping embarcadero would add both the Kinect controller component and the SAPI 5.4 voice component to the next rev of delphi.
I have been playing with the SAPI 5.4 {SAPI 5.1} but I had to manually add the component.

What I was trying to say is the Mediaplayer should be able to save as a .mp3 without adding any other component.

Kinect controller video Is GREAT!!!!!!!
Would you (could you) work with embarcadero to add a component into the new Delphi rev?

“Have you been hiding in a cave?” YES, And I like my cave.

Troy,
I’d be more than happy to have any of my components integrated into a Delphi release, though I literally have no idea what criteria (red tape, I should say) EMB have for that sort of thing.

I’m willing to bet that if any of my components stands a chance of being integrated into a Delphi release by default it’d be the Social Networking suite.

What would really be clever is to integrate a Component Store into the IDE itself (for free & commercial components/suites)… that way you don’t need source them yourself…. just a thought!

Simon,

I do hope that Allen Bauer reads comments here.
The Video with the Kinect controller was GREAT!!
How do I get the Kinect controller component?
Is there some sample code?
The outline of the room with the Kinect controller was powerful.
Delphi needs stuff like that!!

Troy,
You can get TKinect using SVN (Google “Tortoise SVN” if you don’t already have it)… the repository address is: http://svn.lakraven.com:81/svn/OpenSource/Kinect/
The username and password are both anon

The SVN repository is kept up-to-date with the very latest version of the source.

Yes, a demo is included (and more demos are due to be released in the next two weeks). The demo shows: Controlling the Kinect’s LED color, moving the motor mount, capturing RGB and Depth frames, and my own algorithm to determine “Range to Target” (the demo tracks farthest, closest and center target ranges in millimeters)

The video you saw was made by Aleks at ITSecurityLab.eu (using the TKinect component). After seeing what he was doing with the component, I invited him to work with me on TKinect itself, so now we’re collaborating to make the Motion Tracking Subsystem… that is where the Kinect is useful 🙂

Simon,

Thank you for your help.
I guess I need to talk to the boss(My wife) and then buy a Kinect box soon.
The Kinect Video are great!! Thank you for doing the hard work!!!!

Comments are closed.