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:
Wings of Wind Software 
The only thing I took away from my foray into C# that I really liked was the += operator.
It’s pretty nice being able to say
AStr += BStr;
instead of
AStr := AStr + BStr;
That’s my two cents. Otherwise, I remain firmly in the Delphi camp.
I am a Microsoft Certified Developer but that was a tip of the hat to staying up with times and getting the credentials people want to see.
You might use something like Inc( AStr, BStr ); then instead?
While the idea can be applied (see my other reply to Jay) I think that in this case, Inc means ‘increment’ so isn’t quite self documenting. Also,
IncandDecexists because it generates (at least in the past) much more efficient code than + and – . I don’t know nowadays. Normally, the compiler should optimize this.Well, that’s a whole interesting discussion by itself. FreePascal gives the option to accept C++-like operators, and for some people that thing is really important.
Operators has a big impact in programmer’s migration path between languages. If you go to a language where you have already known operators, then you will fell more comfortable. That only thing just makes you feel the learning curve is easier.
This is somewhat controversial anyway, since our “pascal-sense” does not allow many of us to use that operators in pascal code. It’s an heresy for our “pascal-orthodoxy”. But there is that double-slash comment introduced in Delphi so many versions ago, which has become almost the default for comments.
It’s not a MUST, but I like to have the chance of using those operators when I want, they let you write easier code under some circumstances, but for some people can be more than a like-to-have. I think it’s more than a language flexibility feature, it’s an interesting way to make the capture of new pogrammers for the platform easier, speacially migrating from the different dialects of the C language. Of course that if you look at this subject only under that perspetive it’s just syntax sugar for marketing porpuses, yes, but there is something more, it’s also a thing that makes powerful the language itself, and we all want to code in the most powerful language possible.
“Well, that’s a whole interesting discussion by itself. FreePascal gives the option to accept C++-like operators, and for some people that thing is really important.”
Didn’t know that. FreePascal guys rock! 🙂
If your example is about strings it seems very counterintuitive to use the increment operator to concatenate strings – disregarding the fact that repeatedly concatenating strings is neither fast nor memory efficient.
Why save 0.7 seconds writing a line when it may cost hours for the people (among them, you) reading it (and some unspecified time for those *using* the program)? No, spend the extra second and save for the future!
If your example is about integers, the Inc(…) procedure is already there, has been there from the very beginning, and *is* the Pascal way of saying +=.
So, you want something like…
Of course you can enhance this by adding:
– overloaded versions …and/or
– a variant version …and/or
– a generic version …and/or
– an array version (ie. a version to concatenate a variable number of strings:
function Add(var aStr: string; aPieces: array of string): string;– make it a function to return the concatenated string.
Perhaps the last one needs a little explanation:
And to use it…
foo:='Testing'; bar:=Add(foo, ' Delphi'); if foo = bar then ShowMessage('Everything is ok!');There is a function like that already: Concat().
Add() for strings is nonsense, since you are not adding them, you are concatenating them.
The += operator means that the original string is modified ‘in place’. Str1 += Str2 whereas Concat is totally equivalent with + (just slower). And yes, perhaps, the function name isn’t the best one but I didn’t found a better one to be also short and descriptive. But if you have a better idea…
Ok, currently Concat does not do that “in place” anymore. I have no idea whether it is slower or not. Fact is that Add() is a wrong name. += is IMO just as wrong.
A better name would be Append(), I guess:
Append(OrigStr, TailStr);
Note that for complex string manipulation, you can better use TStringBuilder, which already has an Append method.
I was thinking also on some kind of standarisation for component creation, something like an Embarcadero certified best practices for component interface, what i mean is the usability between Raize components ans TMS software components, the first one are very straight foward and user friendly, the last one, it is not.
Pingback: Community pulse: New ways to enhance Delphi « Wings of Wind Software
This is the reason I read wings-of-wind.com. Unbelievable post.
science tattoos,