I'm currently exploring different integrations that can be done between Google App Script and Git. This is part of a bigger attempt to integrate Git data into my project management system. I'll post more on that later. GitHub supports a number of very nice sub-systems. One of them is the GitHub Issues ticket tracking system. It's fairly robust and comes with GitHub - which means it's highly integrated out-of-the-box. Integration with Google's App Script is done via the fetchURL command and JSON object manipulation. After a good bit of experimentation, I've settled on querying GitHub Issues with an "on open spreadsheet event" to avoid issues with Google's quota system. Essentially, Google prevents you from calling the fetchURL command more than X times (see the quota limits ) per day. That's not great if you have people actively working and changing data in a spreadsheet. Some of my other App Script routines are running thousands of times per d
For everyone who isn't hiding under a rock, Embarcadero has agreed to acquire CodeGear from Borland. I'm sure all of us who have been annoyed with Borland for the last 5 years are relieved that the other shoe has finally dropped.
Why 5 years you ask? Let's call a spade, a spade, and say the last really good release of Delphi was Delphi 7 until Delphi 2007 hit the scenes. That comprises a 5 year window where Delphi basically floundered around trying to be things that the core audience really didn't care about in a way that hurt sales and led everyone to assume that there would not really BE another good version of Delphi... ever. Fortunately, Delphi 2007 came out and changed that. Not right off the bat, it did take a service pack (or two) to get things flowing relatively smoothly, but I think everyone pretty much agrees that 2007 is the version to beat now.
The biggest question is probably, "What's the future of Delphi?" Not in a "Delphi sucks" sort of way. I love Delphi. It's my preferred language for any and everything. Even where it isn't quite right, I still try and cram it in. My company even wrote it's own Delphi-script library. If that isn't love, I don't know what is. What I mean by the question is really two parts : first, where are the new Delphi developers coming from and secondly, where is Delphi going?
New developers are the life blood of a language. Once the language stops attracting new developers, it's pretty much dead on the vine since everyone who is currently using it will, eventually, retire and/or move on. The positioning of Delphi in Eastern European schools is a great first step to preventing this problem. I actually think that a stronger academic program, up to and including giving the software away to academics, makes a lot of sense for both Embarcadero and the community as a whole.
For the second question, I realize that anyone can point to the roadmap and say, "See, this is where we're going"; however, I think that the roadmap is extremely limited and doesn't discuss, in detail, the types of things that the language really needs. Part of that is, perhaps, due to the formerly public nature of CodeGear. The remainder is that the language has traditionally been controlled by just one company. Not Pascal the language, but the most widely used derivative of Pascal known as Delphi.
It would be interesting if Embarcadero would split the compiler (bpcc) off as an open-source project and build the libraries and IDE on top of it. That appears to be a winning strategy for Java (ala JBuilder), why not Delphi? In fact, why have multiple different IDE's at all? Why not leverage Eclipse (again, ala JBuilder), and cut a lot of development time and effort out. Isn't code reuse a good thing?
Everyone always complains about open-source software because "there is no money" in it. I'm not suggesting that anything besides the compiler needs to be opened up. When I buy Delphi, I'm not really trying to gain access to the compiler. What I am interested in is the RAD IDE and the libraries (value-added) that CodeGear makes available to me. In fact, FPC as the compiler might be an interesting revision to bpcc. It covers the majority of the goals that CodeGear has on the roadmap (64-bit, multi-CPU, multi-OS) and is close to being Delphi-compatible. Regardless of open-sourcing bpcc or using fpc, an open compiler would both permit other developers to correct issues in the compiler and reassure developers that the tool they've chosen to put millions of lines of code into isn't going to die.
Additionally, the language is being threatened with further fragmentation as the multi-core (or parallel) extensions are being added. If you look at the work RemObjects has done with Oxygene, you can see that the ideas they have advanced (and modifications to the core language), are both useful and straight-forward. CodeGear hasn't, to my knowledge, made public their vision of what parallel extensions they are going to offer. Allen Bauer has blogged about some of the issues, but not in the kind of depth that RemObjects has shown. Parallel extensions is a core competency that could extended Delphi to be the best option for the multi-core CPU's that we are all using and create interest in the wider development community. With an open-sourced compiler, we could have multiple contributors working to build the core language without causing the fragmentation.
To further compound the issue, Delphi's fabled RAD environment should have been brought to the Web years ago in a way that makes web programming (and I'm not referring to html here) easy for everyone. For an excellent example of what I'm talking about, look at Morfik. They have a RAD environment that supports most of the Delphi-syntax (and most of the Delphi IDE functions too) that lets developers develop applications using familiar paradigms. Isn't that the whole point of buying tools? Not to spend 12 months retraining, but to buy something that makes the transition to a new environment easier.
Finally, the days of Windows being the only operating system to develop for are either already over or nearing an end. If you think this is a poor prediction, consider that Microsoft has recently released software to manage Linux servers. Between Mac OS X and the various OSS (mostly *nix) platforms, the world of homogeneous software stacks is on the way out. This doesn't even consider the tiny mobile world that has developed. Palm has sold over 1 million Centro's running Palm OS. Of that market, the current incarnation of Delphi can tap exactly 0%.
Hopefully, Embarcadero will bring vision and funding to Delphi (and all of CodeGears products) in a way that we haven't seen in far too long.
Why 5 years you ask? Let's call a spade, a spade, and say the last really good release of Delphi was Delphi 7 until Delphi 2007 hit the scenes. That comprises a 5 year window where Delphi basically floundered around trying to be things that the core audience really didn't care about in a way that hurt sales and led everyone to assume that there would not really BE another good version of Delphi... ever. Fortunately, Delphi 2007 came out and changed that. Not right off the bat, it did take a service pack (or two) to get things flowing relatively smoothly, but I think everyone pretty much agrees that 2007 is the version to beat now.
The biggest question is probably, "What's the future of Delphi?" Not in a "Delphi sucks" sort of way. I love Delphi. It's my preferred language for any and everything. Even where it isn't quite right, I still try and cram it in. My company even wrote it's own Delphi-script library. If that isn't love, I don't know what is. What I mean by the question is really two parts : first, where are the new Delphi developers coming from and secondly, where is Delphi going?
New developers are the life blood of a language. Once the language stops attracting new developers, it's pretty much dead on the vine since everyone who is currently using it will, eventually, retire and/or move on. The positioning of Delphi in Eastern European schools is a great first step to preventing this problem. I actually think that a stronger academic program, up to and including giving the software away to academics, makes a lot of sense for both Embarcadero and the community as a whole.
For the second question, I realize that anyone can point to the roadmap and say, "See, this is where we're going"; however, I think that the roadmap is extremely limited and doesn't discuss, in detail, the types of things that the language really needs. Part of that is, perhaps, due to the formerly public nature of CodeGear. The remainder is that the language has traditionally been controlled by just one company. Not Pascal the language, but the most widely used derivative of Pascal known as Delphi.
It would be interesting if Embarcadero would split the compiler (bpcc) off as an open-source project and build the libraries and IDE on top of it. That appears to be a winning strategy for Java (ala JBuilder), why not Delphi? In fact, why have multiple different IDE's at all? Why not leverage Eclipse (again, ala JBuilder), and cut a lot of development time and effort out. Isn't code reuse a good thing?
Everyone always complains about open-source software because "there is no money" in it. I'm not suggesting that anything besides the compiler needs to be opened up. When I buy Delphi, I'm not really trying to gain access to the compiler. What I am interested in is the RAD IDE and the libraries (value-added) that CodeGear makes available to me. In fact, FPC as the compiler might be an interesting revision to bpcc. It covers the majority of the goals that CodeGear has on the roadmap (64-bit, multi-CPU, multi-OS) and is close to being Delphi-compatible. Regardless of open-sourcing bpcc or using fpc, an open compiler would both permit other developers to correct issues in the compiler and reassure developers that the tool they've chosen to put millions of lines of code into isn't going to die.
Additionally, the language is being threatened with further fragmentation as the multi-core (or parallel) extensions are being added. If you look at the work RemObjects has done with Oxygene, you can see that the ideas they have advanced (and modifications to the core language), are both useful and straight-forward. CodeGear hasn't, to my knowledge, made public their vision of what parallel extensions they are going to offer. Allen Bauer has blogged about some of the issues, but not in the kind of depth that RemObjects has shown. Parallel extensions is a core competency that could extended Delphi to be the best option for the multi-core CPU's that we are all using and create interest in the wider development community. With an open-sourced compiler, we could have multiple contributors working to build the core language without causing the fragmentation.
To further compound the issue, Delphi's fabled RAD environment should have been brought to the Web years ago in a way that makes web programming (and I'm not referring to html here) easy for everyone. For an excellent example of what I'm talking about, look at Morfik. They have a RAD environment that supports most of the Delphi-syntax (and most of the Delphi IDE functions too) that lets developers develop applications using familiar paradigms. Isn't that the whole point of buying tools? Not to spend 12 months retraining, but to buy something that makes the transition to a new environment easier.
Finally, the days of Windows being the only operating system to develop for are either already over or nearing an end. If you think this is a poor prediction, consider that Microsoft has recently released software to manage Linux servers. Between Mac OS X and the various OSS (mostly *nix) platforms, the world of homogeneous software stacks is on the way out. This doesn't even consider the tiny mobile world that has developed. Palm has sold over 1 million Centro's running Palm OS. Of that market, the current incarnation of Delphi can tap exactly 0%.
Hopefully, Embarcadero will bring vision and funding to Delphi (and all of CodeGears products) in a way that we haven't seen in far too long.
Comments