I had the honor of being interviewed by Huw Collingbourne, the editor of Bitwise Magazine. It got a little long, but if you've been reading this blog for any length of time, I've been known to get a little wordy ;-).
Its surely interesting to address Multi Cores and definitely should be addressed. Have you had a deep look in to Open MP? (its open <g>) I do believe however that from the current state of Delphi compiler you could reach higher performance by adding compiler optimizations than by adding 1 Core...
I was about 1/2 way through reading your interveiw, when you were talking about Linux. In my view it wasn't a technological success since I wasn't able to ever get it working on my distro of choice at the time. (I believe it was Mandrake).
However I had a neat idea. Instead of compiling to obj files, in whatever format, why not compile to a very generic C/C++ source file. The neat thing about this, is it leverages the universal acceptance of C/C++ on all platforms. So even if your system didn't work on platform X, you could consivably compile to C/C++ (and it doesn't have to human readable) and then copy the code over to the platform, recompile and voila, you've got Borland software running on Platform X.
Of course platform specific code would not translate over, (vcl for example). But with a good interface-needs specification, that could be got around for all but the most esoteric functions.
We all know that Delphi is the most powerful programming language ever, but to surviive it must continue improving.... I have a few suggestions for the development of the Delphi Language, many of these are in RemObjects Chrome:
1- Simplified Threading, see chrome's asynchronous methods, you could still use synchronize to access non-MT code!!!
2- Ability to use any type in "case" even strings and classes.
3- Multicast Events Would be nice, with the ability to enable/disable some or all at runtime (saves you the Button14.Onclick=nil; doit; Button14.Onclick=Button14Click;)
4-Cross Compile Apache Modules and CGI for Linux/32 and Mono from Windows
5- Allow ClientDataSet to import/export XML data only (without changesets) with a user-defined DTD, maybe even a property as in ClientDataSet1.DataXML:=MyData; this data could have come from a web service or a webpage or even a text file....
Since people are tossing suggestions about, why not a helper for types?
Type
TMyIntegerHelper = Helper For Integer
Function ToString : String;
End;
Function TMyIntegerHelper.ToString : String;
Begin
Result := IntToStr(self);
End;
Self would be an implict parameter, typed for whatever the type is. Integer, string, pointer, object, whatever. It is really just an extension of the current types, only it could also cover value types.
It is important that it also be able to work on instance and constant values, like :
form1.caption := tag.ToString+' '+2.ToString;
I think it is a natural extension of the whole helper concept.
Oh, and you can tell 2.0.toString is a float instead of a function name because 0 can't be a function name, so it would HAVE to be part of the #.
I think that first of all must be done native unicode VCL! Delphi for Win32(In future also Delphi for Win64 and I hope Delphi for Linux) is only that part of BDS that will be developed most actively, because it has highest RAD performance and excellent final application productivity and many other benefits (unlike applications written in .NET no matter in which development tool). And also Delphi for Win32 is not just simple IDE, VCL is pretty nice mask of Windows API like framework and its an alternative of .NET monster, which is involving more and more developers, because microsoft's marketing is working hardly :)
No magic is in .NET, it's just tool for microsoft to sell much more Windows OS! I think DevCo must leave .NET side and go in other independent way!
Please keep your comments related to the post on which you are commenting. No spam, personal attacks, or general nastiness. I will be watching and will delete comments I find irrelevant, offensive and unnecessary.
Its surely interesting to address Multi Cores and definitely should be addressed. Have you had a deep look in to Open MP? (its open <g>) I do believe however that from the current state of Delphi compiler you could reach higher performance by adding compiler optimizations than by adding 1 Core...
ReplyDeleteMore then a few simple optimizations are still possible, keeping variables in registers more effectivly for example.
ReplyDeleteI was about 1/2 way through reading your interveiw, when you were talking about Linux. In my view it wasn't a technological success since I wasn't able to ever get it working on my distro of choice at the time. (I believe it was Mandrake).
ReplyDeleteHowever I had a neat idea. Instead of compiling to obj files, in whatever format, why not compile to a very generic C/C++ source file. The neat thing about this, is it leverages the universal acceptance of C/C++ on all platforms. So even if your system didn't work on platform X, you could consivably compile to C/C++ (and it doesn't have to human readable) and then copy the code over to the platform, recompile and voila, you've got Borland software running on Platform X.
Of course platform specific code would not translate over, (vcl for example). But with a good interface-needs specification, that could be got around for all but the most esoteric functions.
in fact, it is a David I. "photoshoped" picture ... ;-)
ReplyDeleteWe all know that Delphi is the most powerful programming language ever, but to surviive it must continue improving.... I have a few suggestions for the development of the Delphi Language, many of these are in RemObjects Chrome:
ReplyDelete1- Simplified Threading, see chrome's asynchronous methods, you could still use synchronize to access non-MT code!!!
2- Ability to use any type in "case" even strings and classes.
3- Multicast Events Would be nice, with the ability to enable/disable some or all at runtime (saves you the Button14.Onclick=nil; doit; Button14.Onclick=Button14Click;)
4-Cross Compile Apache Modules and CGI for Linux/32 and Mono from Windows
5- Allow ClientDataSet to import/export XML data only (without changesets) with a user-defined DTD, maybe even a property as in ClientDataSet1.DataXML:=MyData; this data could have come from a web service or a webpage or even a text file....
6- Why not Generics, Class Contracts, ..etc.
Good Luck at DevCo
case Sender of
ReplyDeleteButton1: DoSomething1;
Button3: DoSomething3;
else DoSomethingElse;
end;
Since people are tossing suggestions about, why not a helper for types?
ReplyDeleteType
TMyIntegerHelper = Helper For Integer
Function ToString : String;
End;
Function TMyIntegerHelper.ToString : String;
Begin
Result := IntToStr(self);
End;
Self would be an implict parameter, typed for whatever the type is. Integer, string, pointer, object, whatever. It is really just an extension of the current types, only it could also cover value types.
It is important that it also be able to work on instance and constant values, like :
form1.caption := tag.ToString+' '+2.ToString;
I think it is a natural extension of the whole helper concept.
Oh, and you can tell 2.0.toString is a float instead of a function name because 0 can't be a function name, so it would HAVE to be part of the #.
I think that first of all must be done native unicode VCL! Delphi for Win32(In future also Delphi for Win64 and I hope Delphi for Linux) is only that part of BDS that will be developed most actively, because it has highest RAD performance and excellent final application productivity and many other benefits (unlike applications written in .NET no matter in which development tool). And also Delphi for Win32 is not just simple IDE, VCL is pretty nice mask of Windows API like framework and its an alternative of .NET monster, which is involving more and more developers, because microsoft's marketing is working hardly :)
ReplyDeleteNo magic is in .NET, it's just tool for microsoft to sell much more Windows OS! I think DevCo must leave .NET side and go in other independent way!
Go Delphi! Go DevCo!
in fact, it is a David I. "photoshoped" picture
ReplyDelete