We ended the first technology preview stage of our new tool – FileWatcher (we spoke about it here) and we’re heading to a release. There are significant improvements and additional features to that early version posted there, (btw, if you want something in special, you can post it in comments, or send an email) but now I don’t want to speak about these.
I rather want to speak about another human phenomenon which we encountered during the construction of this tool. Because we started something from scratch, we did an experiment: without compromising the product’s quality, we wanted to use Delphi as much as possible and any other 3rd party library (especially our libraries) as sparingly as possible…
First of all, working again with the bare language, reminded at least two of the language enhancements which Delphi can add – one was the extending of the
Case statement (article here, QC report here, a somewhat related UserVoice request here) and another one was the missing of
step clause for a
for cycle. (QC report here). And it seems from our pie on the right, that others share the same opinion. A note on the ‘Other’ part: almost all the entries in the ‘Other’ edit were a ‘Yes’ but presented in different – one of the most interesting was “support all kind of expressions like CASE in SQL”
…but the main problem was with the Delphi’s VCL / RTL. There were three categories: the ones who we used heavily in our project (no problem here – this is good), others who we didn’t use and we didn’t interested to use them (this is so and so – one can regard them as ‘bloat’ but others can see them as ‘just not doesn’t fit for this type of project’), but finally there were some things which we really wanted to use but the implementation was (in our humble opinion) not very ‘adequate’ to the needs of a programmer in 2009 so we needed to rely on 3rd party solutions. (Sons, a DB grid really needs to have a checbox on a boolean field and/or the possibility embed controls, you know… Yes, we know that we can fake it).
The somewhat good news were/are that the team is somewhat aware of some problems that we’re facing – the survey shows that. But I think that the survey was/is quite big (as the Team warned us from the beginning) and somewhat difficult to fill – and one of the main causes was as they stated “Embarcadero does not collect data…”
Well, I think that this can be improved.
I think that it would be a very nice thing to have a scanning engine, like the old VCLScanner to get usage data – of course, this perhaps needs to be updated in order to be compatible with all Delphi versions in the wild. I think that this would be a very useful tool in order to see which are the components which are actually used, a basic thing for the cross-platform step, in my humble opinion, because they must know what we are use most in order to know where to stress their attention and where to skip. We must remember that unity with the team (if both we and they will know to leverage this) will give us the strength to go forward.
This data must be in human-readable format and it should use the default eMail client installed on developer’s machine to send it to Embarcadero. Of course, it will be the developer’s responsibility to push the ‘Send’ button, after he will review the data which will be sent. (Ok, perhaps not many will check it, but I think that this is a necessary step due of obvious reasons – privacy, security etc.).
As an aside, this data can be used by the developer itself in order to know what is used in his project(s) (and what not) and in what percentage – giving him enough decision making hints (what to maintain, what to enhance, where to consolidate, what to drop etc.)
Not to mention that the team (ok, at least some of them 😉 ) is interested on this kind of things so feel free to comment and vote: