Blogged - Delphi Language Enhancements
Blogged - Delphi Language Enhancements
https://www.finalbuilder.com/resources/blogs/postid/750/delphi-language-enhancements
https://www.finalbuilder.com/resources/blogs/postid/750/delphi-language-enhancements
I disagree with most of your proposal :)
ReplyDeleteWow ! That is a really nice wish list. Idea to take experienced 3rd party developers (A. Bouchez, Primož Gabrijelčič, Eric Grange, Stefan Glienke, Andreas Hausladen to name a few) is also nice... Brillant post.
ReplyDeletePaul TOTH That's fine, just ignore those features if they ever appear ;)
ReplyDeleteI find it odd that people want try except finally in one block. I almost never write nested except and finally. ln fact I hardly ever write except. Is the real issue people handling exceptions where they should not?
ReplyDeleteVincent Parrett, nice list I must say.
ReplyDeleteI have some comments though
Regarding
** Allow Multiple Uses clauses
You can bypass that issue by writing each used unit in a new line.
** Variable method arguments
This is possible at least in Seattle
DoSomething( [1 , 2, 3 ]);
You do have to add the square braces as I did above and remove the params in the procedure declarations.
David Heffernan : I mainly write try finally blocks and have sometimes to write nested try except finally blocks This would be a nice addition IMHO
ReplyDeleteGood list!
ReplyDeleteA couple of quick observations
* CaseSensitive. It is by default, if you need it not to be, you write:
case Lowercase(s) of
'hello' : x := 1;
'goodbye' : x := 2;
sWorld : x := 3; //sWorld is a string constant
end;
* Ternary - Instead of the ?, I would prefer:
x := If y = 0 then 0 else 99;
Here is another idea
x := case y of
0: 0;
1: 5;
else 99;
end;
Stéphane Wierzbicki My point is that I wonder why people are handling exceptions in the first place. Don't you just let them float up the call stack?
ReplyDeleteNice list Vincent Parrett, got several of those in DWScript for a few years now, with basically the same syntax in most cases :)
ReplyDeleteFWIW, of those you listed that DWScript also has, the highest amount of positive feedback and usage is for:
- inline variable declaration & type inference (users could no longer live without it)
- inline loop variables (usage ramped up very quickly when users learned about it)
- generalized case..of (basic user expectation, the only ones that had to be told it was possible were Delphi devs)
- multiple uses clauses (another basic user expectation)
Good feedback, but limited use in the field (advanced users only)
- property shortcuts
- partial classes
- generalized helpers
- ternary operator
- lambdas
- async/await (case-specific support at the moment in DWScript)
Almost no feedback, rarely used:
- try except finally
- operator overloading on classes (and in general)
- linq
And those features not yet in DWScript (so no feedback) but that I want to add.. someday:
- variable method arguments
- named arguments
- yield
David Heffernan If you work with a live stream of unpredictable input data, you need to decide at what level you want the call stack to recover. A bad number? A bad date? A reference number not present in data received until now? A value that is outside the normal parameter range (LOG/root/division)?
ReplyDeleteWith live input, is not a question of if, but when. Naturally, NOT having exceptions is the better approach, but shit happens.
Lars Fosdal Sure. But you don't want to be handling exceptions all over the place. Otherwise you may as well handle such errors the traditional non-exception based way. If you are using exceptions, you want to centralise the handling of them. In which case why is there such a compelling need for try/except/finally?
ReplyDeleteI love most of your suggestions except the one-block-try-except-finally*. Many of them have been suggested in the early field test forums and RAID, likely also in QC. Those media didn't help getting these features there,, so I tried direct talking to Delphi team members to propose (same for sponsoring open source libraries). That hasn't helped much either. My impression is that these features don't win enough "feature ticks" on the boxes, take a long time to implement and only help developers, not decision makers. With the brain drain at R&D these features will take an even longer time to implement. It's one of the reasons I made my statement yesterday about chances of things getting fixed are getting lower over time.
ReplyDeleteThe lack of language features is actually the most important reason frameworks like Spring4D and DUnitX have such a large and convoluted amount code. This beside the fact that they need to support Delphi versions back to around 2010 which was about the last time real language features were added and working around their bugs as it was taking about 3 versions for the most severe bugs to get fleshed out.
Without compelling new features like the ones you suggested and the "getting it right in one version without need to install updates", the base of Delphi developers will continuing become shallower and shallower. The developer base is mainly consisting of two groups anyway: the people that have been there a long time (they're slowly dying out) and the groups that try Delphi for a while before moving on. My impression is the last group has a fairly steady influx and outflux, so it's a good way for making money on for Idera. But they don't form a good enough steady base nor bright future for people that want to build and maintain quality code in Delphi for like 5+ more years.
* In the past I've done statistics research on various languages and frameworks on the frequency of finally/except usage for finally, except and combinations. Finally is the huge winner, except about an order of magnitude less usage than finally, and the combination is hardly ever used. The main reason is that finally and except are conceptually very different so should never be in one block.
Regarding type inference:
ReplyDeleteVar
Bla = 1;
Could be integer, or byte, or longword, or int64, or any float type.
Blub = 'c';
Could be char, or ansichar, or string, or ansistring.
How should that be resolved?
Jeroen Wiert Pluimers The only reason frameworks like Spring4D, DelphiMocks, DUnitX etc are able to exist is because of language enhancments (generics), but I know from my experience it was a major battle to get them working due to bugs in the compiler.. hence all the ifdefs (not to mention adding zero based strings into the mix ).
ReplyDeleteI think you hit the nail on the head with regards to the two stream customer base. New customers are most likely attracted by the mobile stuff, but its such a mess people don't hang around. Old customers have years of code invested in the product, not easy to move away. I'm one of those, I'd have to think long and hard about writing a new project in delphi, most new stuff these days is web based, and delphi just isn't the tool for that.
I spend more time in visual studio these days, and every time I load rad studio I feel like I'm stepping back in time (codeinsight is still broken!).
My next delphi post will probably be about package management (getit is not what the community wants/needs).
David Heffernan I don't often nest try/except/finally, but sometimes I'm forced to, when calls to libraries raise exceptions and I need to release locally allocated resources. I'f messy, not perfect, but in the real world, we don't always write all the code.
ReplyDeleteUgochukwu Mmaduekwe I'll have to look at seattle & berlin, it's difficult to tell which compiler supports which features when they differ depending on the target plaform (a mess that should never have been allowed to happen imho).
ReplyDeleteThomas Mueller let the compiler decide the optimal size, if it fits in a byte, then use a byte, if you have a specific size requirement then specify a size.
ReplyDeleteNot sure how I feel about multiple uses clauses. Maybe even have them sprinkled all over the interface and implementation section?
ReplyDeleteType
Tbla = class
End;
Uses
controls;
Type
TMyCtrl = class(tcontrol)
End;
No, don't like that. It's too messy. But maybe the IDE could have an explicit uses clause plus one that is automatically maintained, whenever I write something like
Type
TMyCtrl = class(Controls.TControl)
/sub
ReplyDeleteThomas Mueller No not sprinkled, that would be horrible. It's more about allowing for better tooling, like not having the IDE mess things up. In fact, that would be especially useful in the dpr file.
ReplyDeleteI feel so stupid when I see lambda expressions. Inlined for variables, the interface helpers, the ternary operator, the extended case totally make sense and would be nice to have without hurting the readability, simplicity, debuggability in any respect.
ReplyDeleteVitali Burkov I used to when I first saw them, but they are not that difficult to learn, plenty of good tutorials on the interwebs ;)
ReplyDeleteDavid Heffernan My comment was about the need for handling exceptions. That is a real need.
ReplyDeleteCentralizing handing is a good thing, and I expect we all do that.
Data conversion methods that do the checks / handling for you, so that you don't have to sprinkle your code with handlers is one form of centralization.
Wrappers around databases, Indy, and other external components is another.
EurekaLog/MadExcept is the final form of centralization, for handling the cases that went all the way up the stack.
I don't see a massive need for try/except/finally - as it is mostly syntactic sugar. I have a few places where they would reduce the amount of indentation, but I can manage without them. I do guess that people coming from C# would cherish them, though.
Lambdas - clarity and readability can be an issue, but as Vincent says - it's a learning curve.
ReplyDeleteLars Fosdal Obviously they need to be handled somewhere. But if you are handling them in so many places that nesting with finally blocks presents a readability problem, then you are, in my view, likely to be mis-using exceptions.
ReplyDeleteI therefore don't see the point of that language change.
Vincent Parrett that's exactly why you want it to be in two blocks. Two different concepts that you really want to separate to keep the intentions clearly separated. The cases where I bumped into this always had me break up code in separate methods where the naming of them helped making the intention more clear.
ReplyDeleteThomas Mueller ModelMaker Code Explorer helps big time here. In most editing circumstances it will automagically update the appropriate uses list(s).
ReplyDeleteVincent Parrett of inferred variable types and const handling you likely also want const hinting (like C# does with a suffix on the const value indicating the desired type).
ReplyDeleteJeroen Wiert Pluimers Do we need hinting when we can be explicit?
ReplyDeletex := Cardinal(if y=0 then 0 else 99);
Another feature that can be surprisingly useful is the coalesce operator (??), it allows eliminating a lot of not-so-clear if-then-else constructs for handling default values and optional stuff.
ReplyDeleteLars Fosdal That last comment illustrates a fundamental problem with the current design philosophy for Delphi. In many other languages, expressions have a well-defined type. In Delphi, you often find situations where an expression's type is determined at the point of use. I guess I'm thinking primarily of literals.
ReplyDeletePersonally I'd much rather be explicit about this. So instead of writing:
y = 0 ? 0 : 99
and leaving the type of the two candidate literals indeterminate, I'd far sooner see
y = 0 ? 0u : 99u
For floating point I could write 0.1s or 0.1d and leave no doubt as to whether or not I wanted single or double precision.
I hate the fact that
'a'
can be many different types depending on the context of its use.
If being explicit is the goal, then you really want a concise syntax to specify the type of literals.
David Heffernan Actually the expressions you wrote have well-defined type. The problem is that often it is not the type that you would expect. You see that when using type inference with literals (like writing TValue.From('a') or const a = 'a')
ReplyDeleteIf you want a specific type, well then declare that type in your variable or const and don't let the compiler decide for you.
David Heffernan ever observed the subtle difference between #$20 and #$0020 ?
ReplyDeleteDavid Heffernan
ReplyDeleteWe already have the typecast. Do you want to add another notation?
const
a = String('a');
c = Char('a');
u = Cardinal(1);
i = Integer(1);
b = Byte(1);
Strangely, the floats are not supported, so we can't currently use
d = Double(0.1);
s = Single(0.1);
Stefan Glienke Not always well-defined. Sometimes it is determined by context.
ReplyDeleteLars Fosdal Why are you making up new syntaxes for what we already have? Declare the type if you want to be explicit - let the compiler decide if you want to be implicit. Problem solved.
ReplyDeleteconst
a: string = 'a';
c: Char = 'a';
u: Cardinal = 1;
i: Integer = 1;
b: Byte = 1;
d: Double = 0.1;
s: Single = 0.1;
Stefan Glienke The cast is hardly a new syntax. It's just not consistent for constants.
ReplyDeleteJust to clarify - how would you declare a constant value with a user defined type?
Stefan Glienke I have also been sometimes annoyed by the inability to have an explicit Double or Single literal: you need to use a named constant for that, which results in different code generation by the compiler (explicit memory load/store rather than simple stack push for parameters, no compile-time evaluation of simple expressions, etc.)
ReplyDeleteSupport for cast syntax like Lars Fosdal posted would be fine and similar to other types.
Stefan Glienke That's fine if you want to name a constant, but not helpful for inline literals.
ReplyDeleteVincent, the list is very interesting and a lot of the ideas you listed are on the table. The only omission I see is nullable types, but maybe because we announced this is being worked on.
ReplyDeleteSome of your suggestions will require some more thought. For example your example of type inference assigning 99 and deciding for Integer will conflict with type inference for constants. It can be done, but there are subtle details that can cause trouble. More than open to go over individual features, as the devil is often in the details (and some of the discussion here highlights it, like for uses clauses).
The main element of disagreement comes from your premise, the Delphi language "really hasn't changed all that much in the last 20 years". That makes no sense and helps spreading some total misconception.
I'm pretty sure you know how the Delphi 2 language was (that's 20 years ago). We can easily create a much much longer list of features that have been added to the language. And I'm not talking of the main additions you also mention, but the large number of other additions.
/sub
ReplyDeleteMarco Cantù I used delphi from D1 in 1995, yes there have been some incremental changes over the years, but they are minor compared for example C# 1 to C# 7 and look at the differences, C# has evolved a lot more over a shorter period of time. In recent times, the language has barely changed, the zero based string debacle doesn't count.
ReplyDeleteI don't have the delphi compiler source, so I can't pretend to know the difficulties in implementing the features.
I'm not sure I understand what you mean by conflicting with type inference for constants? Surely the same rules could be applied, I have no idea what the rules are, my google foo has let me down on that one. Doco reference?
> C# has evolved a lot more over a shorter period of time
ReplyDeleteThat's true, but it doesn't mean Delphi language hasn't evolved. Evolution has slowed down in recent years... particularly if you don't count in mobile.
> conflicting with type inference for constants
A constant with value 99 will be defined as a byte. A variable with a value 99 you'd probably want as an Integer (by default). This would create a discrepancy in expectations, nothing that cannot be worked around.
Nice list. No multi-line string declaration like Python?
ReplyDeletestackoverflow.com - Pythonic way to create a long multi-line string
Vincent Parrett Great list, well presented!
ReplyDeleteMarco Cantù Great to hear you are open to discussing these items and that some are already in discussion.
I am very excited about the possibility of most of these items and would like to know if you think there could be a way to define exactly what people would want from these language features, with some examples and rules which could then be assessed by yourself / Nick / dev team and come back with problems or alternates in the case some other considerations are required?
This could be a select group of people who could work on the details and then arrange an online discussion over any such documents.
Vincent`s examples seem like a good starting point.
Martin Sedgewick We have in fact a plan to engage with a few community members around the language, something we already do in direct conversations. But Linux has priority right now.
ReplyDeleteMarco Cantù Great to hear. There are some brilliant minds in this community who I am sure would love to discuss these features.
ReplyDeleteLooking forward to Godzilla! and beyond :)
David Heffernan, IMHO with exception catching you can centralize error handling in a single place, in scenarios where a lot of kinds of error might happen, for example, when doing networking. Below is a link to a page which describes what I said better, which I wanted to post here earlier ;)
ReplyDeletestackoverflow.com - Which, and why, do you prefer Exceptions or Return codes?
Love the inferred types, inline vars, and lambdas.
ReplyDeleteVincent Parrett There's a reason why C# changes a lot in 7 years and Delphi not so much. If you can't work it out yourself, you have no right posting lists like this.
ReplyDelete+1 Local variable initialization. -1 Personally I really dislike inline variable declaration. +1 Non-ordinal based case statements. -1 TryExceptFinally...looks like a broken Delphi code fragment. -1 Multiple Uses Clause (fix the IDE mangling instead) The rest have some merit to attract new devs but in general, I'd rather have Linux server support and more bug fixing. But at a basic usability level, they need to improve the install process making it much more friendly to frequent VM deployments, including reworking licensing (finally add the ability to de-activate a license!)
ReplyDeleteWhile I certainly think Delphi has a lot of catching up to do in the language department, I think it's flat out wrong to say the language hasn't changed much in 20 years.
ReplyDeleteBetween operator overloading, generics and anonymous methods you can write some pretty neat stuff that was not possible in D7, far short of 20 years.
David Heffernan Some libraries (like say Indy) throws a lot of exceptions that one normally wouldn't want to bubble out. And often one wants to use some resources with the calls, say streams and whatnot... In such cases I find I often have nested except/finally.
ReplyDeleteVincent Parrett RE: Partial classes... Those would only be possible if EMBT would implement my proposed Link-Time Code-Generation (LTCG). The reason is that you cannot precompile into a DCU the code and layout of a partial class because at the point the compiler is building the DCU it is unaware of any other components to the partial class. Only once all the references are resolved and the linker kicks in can the full context be known. The C# compiler does exactly this.
ReplyDeleteWhile LTCG would enable partial classes, it's much larger motivation is vastly increased DCU compatibility across major updates. Except in cases where methods are removed/renamed and a couple of other very obscure cases, moving to a LTCG model would make DCUs far more resilient... not to mention the possibility of adding WPO (Whole-Program Optimizations).
Lest you worry that this would grossly affect compiler performance, this system would also generate DCU files that do contain the actual generated code and cache them on a per-project basis. There would be no need for "Debug" DCU files to be delivered with the product since the delivered DCU files would be delivered in the intermediate, LTCG-compatible format. Initial builds may take marginally more time to generate, but subsequent builds will be as fast as before.
The compiler already persists compressed node-trees due to inline functions and generics. Expanding this to cover everything would be the next step. For platforms that don't use the built-in linker, there would need to be a "pre-linker" phase that does the LTCG. This generates the object files which are then passed to the platform's linker for final generation of the image. The pre-linker (along with the existing integrated linker) would also do the WPO pass.
Make no mistake, this is no trivial or simple task and would require a much larger heavy-weight compiler team...
There are already tools like this for C++ around CLANG and LLVM, so C++Builder would also be able to some of the same things.
Allen Bauer Good to see you, man! I wish you and a rock solid compiler team was still around.
ReplyDelete/sub
ReplyDeleteLars Fosdal Sigh. They, AFAIK, still have a rock-star compiler developer... unfortunately, any significant compiler changes will require a larger, very focused team.
ReplyDeleteAllen Bauer https://www.youtube.com/watch?v=uL0ROeZw7wA :P
ReplyDeleteVincent Parrett
ReplyDeleteVar
W1 = 255; // fits in a byte
W2 = $FFFF; // fits in a word
Begin
W1 := w1 + 3; // boom
W2 := -6; // boom
"W2 = $FFFF; // fits in a word"
ReplyDeleteAre you sure? How do you know it's not a signed integer? What about "W2 = 65535;"? It's the same value, no? Why would specifying the value in hex make a difference?
Do you favor signed integers over unsigned? Why or why not?
Allen Bauer Any word on parameterized methods on interfaces? Today a coworker and me were thinking about the problems with that since currently any specification of such a method causes the compiler to generate the code for the method with that type parameter. But if you have that on an interface how can it know which implementation to generate the code for, right?
ReplyDeleteSo I was thinking further - what it we only allow them on interface helpers because then you basically write the implementation of that "extension" method in the context of the helper by just calling other methods of the interface. In such a case the compiler would be able to generate the code for parameterized methods on the caller side of an interface, right?
Similar to what I did here: http://pastebin.com/acp2i645
Stefan Glienke I think you've thought through the problem sufficiently to figure out one reason a parameterized method on an interface is just not feasible.
ReplyDeleteDoing a parameterized method on a helper is, however, possible since the implementing class or the interface are, generally, unaware of the existence of a helper. The methods on the interface helper cannot be virtual (well, they can... but that introduces a whole new set of problems), so making one or more of them parameterized would work. So, as you surmised, the caller side is what controls how the method is instantiated.
Allen Bauer
ReplyDeleteI specified the value in hex, because I was too lazy to convert it to decimal (that's what computers are for). All I needed was the maximum value that can be stored in 16 bits.
That it is difficult to infer the variable type from the value assigned to it was exactly my point.
Thomas Mueller If you intend to be able to infer integer type from the plethora of available sizes, you're correct. However, if you restrict the inference to a sufficiently small subset and clearly define the rules, it's possible to have a very effective type-inferencing system.
ReplyDeleteAdding this to Delphi could, however, change some semantics. Because Delphi has fairly loose assignment compatibility rules, things aren't as straight forward.
Even C++ has pretty strong type-inferencing, both with template functions and using the new "auto" keyword. This also relied on the fact that the C++ standard didn't strictly define type-promotion rules. A lot of that was left up to the implementation, which meant that most C++ developers didn't rely on it.
Delphi is a little different where devs quickly adopt and expect certain compiler semantics, even in cases where it's been clearly stated that it's undefined.
Jeroen Wiert Pluimers There are plenty of specifications on the Wiki and other places. Specifications usually specify things in the affirmative and leave things unspecified as "undefined". A lot of things that the compiler does which folks rely on are actually in the "undefined" category. Going in to call out all the "undefined" things would be kind of silly... some things yes, but not all things.
ReplyDeleteJeroen Wiert Pluimers Allen Bauer having undefined defined would kill a lots of fun ;-)
ReplyDeleteDalija Prasnikar It certainly keeps the peanut gallery employed :).
ReplyDeleteAllen Bauer Thanks for checking in, with some invaluable info as always. I realise that implementing many of these features would require a significant investment, which is contrary to what we have seen from emb/idera in recent times, and I don't realistically expect that to happen. I am however alway happy to be pleasantly surprised (doesn't happen very often!). I guess at the very least, my post has sparked some discussion. I do despair when I see the head in the sand attitude from many delphi developers who don't want to see the language change/evolve. From my point of view, it needs to evolve or continue on it's current path to obscurity.
ReplyDeleteJeff Dyer I must be especially thick, perhaps you could enlighten me as to why I have not right to post what I did?
ReplyDeleteMarco Cantù I didn't say the language hasn't changed at all, sure it has, but apart from generics and anonymous methods most othe changes have been small. What I'm calling for is some investment in the language to bring it into the 21st century.
ReplyDeleteVincent Parrett Philosophical question: Are "language changes" only things that involve a change/addition in syntax or do semantic changes count? I ask because of your contention that very few "language changes" have happened aside from generics and anonymous methods.
ReplyDeleteI would contend that there have been many changes, including richer RTTI, ARC, improved dynamic array syntax & operator support, UnicodeString, AnsiStrings w/ encoding info... Even some low-level RTL enhancements should count for something.
I'm not saying your list isn't interesting, but it seems you're justifying it by making it seem like very little has happened in recent years. It seems like an "it's about time!" argument. Why not present the ideas on their own merits without the commentary and judgement that sets a bit of a negative tone?
At Google, I've found that the proper technique is critical to presenting any new idea, enhancements or change. You will be shot down in flames faster than you can imagine if any critique of existing systems isn't backed up by solid data. I've even found that citing existing art may not be enough.
I often have lunch with Chuck Jazdzewski (he works only a few buildings away) and we both sometimes commiserate about some of the things that could have been. I certainly hope there will be some proper attention paid to the language itself.
Most of all I want reloading "dot" of the operator.
ReplyDeleteThis will do interesting things, such as full TSharedPtr:
Now:
var
a: TSharedPtr ;
begin
a: = TControl.Create;
a.Value.Parent: = Self;
After:
var
a: TSharedPtr ;
begin
a: = TControl.Create;
a.Parent: = Self;
Allen Bauer I purposely ignored semantic changes like unicoded strings, encodings & enhanced RTTI (which is really an rtl/compiler thing). I really wanted to focus on major syntax additions (notice I didn't say changes). I also ignored mobile changes (zero based strings turned me off using the mobile stuff, and I was never able to get much of it working anyway) like ARC which are not available on the desktop compilers.
ReplyDeleteI certianly didn't mean to imply the team did nothing in 20 years, just that the language itself is really not much different from D3 (interfaces was a big/welcome change). If we ignored generics and unicode strings, I could probably back port most delphi code to D3 today with only minor changes. In each release of delphi, with very few exceptions, there has typically been only one or two minor little language enhancements. The last time felt excited by a delphi release was D2010.
I expected there might be some pushback on my post, but it has had the desired effect, people are talking about language features again (rather than mobile this or that).
I am amazed how many people have contacted me to tell me to leave things alone, they like it just how it is etc (some stronger words were used by some, but I won't repeat them here). So many heads in the sand. sigh
Also, I suspect given the current state of delphi, customers would more likely vote for bug fixes rather than language enhancements, which is sad place to be in. In the mean time, I'm having fun exploring Go & Rust in what little spare time I have, and I'm quite comfortable using c# every day.
I didn't see Null Coalescing and Null Propagation operators on the list :(, I think this language design decision need to be considered together Nullable Types syntax.
ReplyDeleteAgreed, I didn't mention nullable types or anything related to it since it's already on the map.
ReplyDeleteVincent Parrett I don't know what Marco Cantù is preparing for the Nullable Type support (I trust him and Embarcadero team :D) however if this support come without some flavour of these operators it would be disappointing :(
ReplyDeleteVincent Parrett "The last time felt excited by a delphi release was D2010." hits the nail on the head for me. I think it's because Delphi has been in a kind of "maintenance" mode for a long time. There have been new features, but they don't work well enough or make me productive enough to excite me, or have been so long overdue that I am glad they are finally there (or coming), but not exited. Win32: IDE crashes on me multiple times a day since ~2009 or runs out of memory (anything with the Kibitz compiler). Win64: way too slow debugger experience. FMX: could have been great, never lived up to it, especially the design time experience. ARC: don't get me started without a Win32 version. Mobile: compiler way too slow. LiveBindings: nice start, way too over-engineered. Generics/Anonymous methods: took way too long to become really stable, still bumping in corner cases, but in a usable state since around XE4. Still bumping into Unicode corner cases. General conventions in the RTL/DB/VCL/FMX layers: very much lacking consistency and completeness.
ReplyDeleteTo me, Delphi is like the "just fine" phrase by Leonard in the Big Bang Theory. I get the most fun with Delphi using Spring4D, TestInsight, Model Maker Code Explorer, GExperts and FixInsight (the non-exiting DDevExtensions and waiting for update-1 are basic requirements using any version). All of them not coming with the product and all of them trying to get us to a level that competing products have already reached a long time ago. Most of them also a one-man thing. And I get fun out of helping other people with Delphi problems. Sort of resurrecting libssh2-delphi was nice.
Another part of the excitement used to come from the R&D team members. None of them are really visible any more and the ones that were haven't radiated a "this stuff is sooooo cool" for a long time whereas other products I use (still) have those people around.
Mind you, Delphi still gets part of my work done (for the last 6 months a bigger part, before that a marginal part) but other products do better. VCL stuff? Delphi. Back-end stuff? .NET. Web stuff? Angular. Plumbing? Powershell, bash. Mobile stuff? Xamarin or web-tools.
Like Allen and Chuck I think on how it could have been. And I hope it will change.
Although there were small additions none of them revolutionized the way we design and write code like generics, anonymous methods and enhanced RTTI did.
ReplyDeleteNot downplaying them but the ability to write myarr := [1, 2, 3] does not fundamentally change my code. Things introduced in Delphi 2010 did. Others have already mentioned the various projects that exist because of those language features.
Vincents list contains both kinds of features. Like local variable initialization will not fundamentally change code but make it less verbose and cleaner. Other things like partial classes or interface/generic helpers can change entire architectures - the day we get these helpers it will change the way we are implementing the rich IEnumerable methods in Spring4D making it way easier to implement IEnumerable somewhere and getting all these nice extension methods (and even more if we can have generic methods on helpers) for free. And for those interested it will reduce binary size because it does not have to compile in any of those methods of IEnumerable but only those that are really ever called via helper.
Stefan Glienke I guess there are two different sets of use cases: type inference will not allow you to do "new" things, but will drastically change the way code is written, and can do wonders to improve scoping and readability of everyday code, and in the end, save time... but just a few seconds at a time.
ReplyDeleteGenerics on the other hand allow new things, drastically change the way libraries can be written, but slightly decrease code readability and simplicity when used in everyday code. So they save time in big batches on the library side, while losing a few fractions of seconds here or there (a TList takes more time to type than TIntegerList f.i. because code suggestions are less effective at suggesting it from a partial input).
Some changes like anonymous methods can benefit all uses cases, and everyone wins.
Excellent idea.
ReplyDeleteEric Grange That is the fault of the tooling (i.e. code completion) if it does not work well with generics. I am not sure if Baoquan Zuo has that on the radar (I think his codeinsight plus plugin does something in that regard) - iirc it treats generic types like these code templates, so you type TL invoke code completion hit enter on the TList type and the editor sits in the place where you enter Integer (or Int enter to auto complete it).
ReplyDeleteStefan Glienke code completion cannot really do anything smart for a generic class declaration because the parametrized type can be any type, so it is not possible to narrow it down in advance. All types in the context are potential candidates, so you're going to need two completions in sequence anyway.
ReplyDeleteVincent Parrett As I mentioned, I do appreciate your wish list, some of those are on the table (along with a few others), but As Allen Bauer mentioned starting the blog post with a negative (and rather pointless) comment, makes it more difficult to get into a conversation and adds no value. For example, if I had to share the post with some of my managers I'd have to explain there is a lot of value but you are wrong on the initial assessment. Just adds an annoyance we could have spared.
ReplyDeleteOut of many and many additions, the for-in loop is one most developers use regularly, along with intrinsic type helpers. But I'm sure you are aware of them, just using an hyperbole. We need further language evolution, and it makes sense to pick great ideas from other languages (like other languages keep picking from Delphi), but not because the Delphi language is a terribly shape. If that was the case, we'd better give up. We need further, continuous improvements to make a great language even better.
Since XE versions there has certainly been plenty of compiler work done, but language evolution is almost non-existent.
ReplyDeleteFew compiler intrinsic routines, few RTTI additions, record helpers for built in types (in Highlander mode, like all helpers are), few string like operations for dynamic arrays and weak, unsafe, volatile attributes can hardly count as language evolution.
Generics, anonymous methods and enhanced RTTI were last significant changes to the language.
But for language evolution one this is crucial. Besides bigger compiler team that can implement language changes, first thing you need is person (or more) capable of envisioning the future and designing the language.
Language needs to evolve in way that serves developers using it, not the other way around. Evolution only makes sense if it will help me do my job faster, easier, if it will make my code cleaner, simpler, easier to read and maintain.
Having said that, one can certainly admire works of Anders Hejlsberg. If there is one language out there done right most of the time - it is certainly C#.
Even with all the money in the world and bunch of really smart people working on it, Swift is more three legged unicorn than well designed language. Yes, it has some really well thought of features, but it also lacks some basic stuff needed for everyday's work.
Delphi has good foundations, it has plenty of potential. Question is whether it has enough visionary forces behind that will drive it in the right direction.
Marco Cantù that is quite a scary comment about your managers...
ReplyDelete"We only consider feature requests if you start the request by stroking our egos."
ReplyDeletePerhaps that's where I've been going wrong. Maybe I should try like this:
Delphi is a truly wonderful product. I can't speak highly enough of it. I think you guys are awesome. Keep up the good work. Oh, by the way, it would be really nice if you could arrange for Set8087CW and SetMXCSR to be threadsafe.
David Heffernan That is a completely hyperbolic mis-characterization, and you know it. It is about setting the proper tone in order to facilitate a discussion. It is not about feigning praise, which will come across as fake and insincere. It is far better to make no judgments and merely present the ideas as dispassionately as possible. Do not mistake being a complete jerk for being passionate.
ReplyDeleteIf it is all about having to prove how smart you are... then you've failed. Miserably.
Vincent Parrett That is how I understood and took your suggestions. I was only trying to assist in helping to hone the message and make it more effective. Trying to boost the argument by implying something that isn't really quite true, only drags down the rest of the ideas. If the ideas cannot stand on their own, then maybe they need more thought. At the end of the day, that is what they must do.
ReplyDeleteAllen Bauer I don't think anybody is trying to prove anything here. I just think that bug reports and feature requests should be judged impassionately. As a developer it's important to see past the understandable frustration of the user asking for improvements, and perceive the opportunity to improve.
ReplyDeleteI find Marco's comment quite disheartening on that score.
David Heffernan Ah yes... the old "I'm the user so I can be a huge jerk" argument. That has never worked with me and I know it has never worked with anyone else. Arguments like that are often ignored or mocked. It's akin to going into the local store, standing in the middle of the isles, jumping up and down screaming to be heard.
ReplyDeleteWell, guess what... developers are people too and deserve the same level of respect and consideration as anyone else.
For the record, I also found Marco's explanation a little interesting.
Dalija Prasnikar re: Swift. I can unequivocally say that even among those at Apple, Swift isn't the be-all, end-all. In fact it's wholly unsuitable as a systems level language. IOW, one could not really write the low-level OS stuff in Swift. Delphi certainly beats Swift on that score.
ReplyDeleteHow do I know this? I turned down an offer from Apple (in favor of Google) for working on their compilers and tools (I think... It was for their super secret black-ops group).
Allen Bauer Who has been a huge jerk here? I don't think Vincent's post was rude. I don't think he was being a jerk at all. I don't think his comments on the state of the language were rude. He was stating his opinion to which he is entitled.
ReplyDelete"starting the blog post with a negative (and rather pointless) comment"
Vincent is a person too. Now he is being called out for making a pointless comment.
If developers won't listen to suggestions if it contains criticism of the product, then that's a pretty poor state of affairs. That was the point my sarcastic comment was meant to make. And yes, sarcasm is seldom useful and constructive. I should know better.
I guess you mean that I am a huge jerk. Probably quite accurate.
David Heffernan I was speaking in the abstract and only to the hyperbolic nature of your comment. I didn't think that Vincent Parrett was being a jerk. I only made a point that his argument would be more effective without the extra opinion about "no significant changes" as an justification for his ideas. I made the point (several times, in fact) that those ideas should (must) stand on there own. The feedback was was about how I perceived the post. Others may have read it differently.
ReplyDeleteHowever, you took this into the strawman (and somewhat cynical) territory and certainly seemed to make the point that the one being presented an argument must be the one to weed out the cruft and hyperbole. That's not how convincing arguments are made. It is incumbent on the presenter to convey their ideas as effectively as possible. If they dismiss or ignore your idea because they were turned off by the tone, then yes, the presenter must bear some of that responsibility. I don't think you were being a jerk either, but seemed to be condoning or at least justifying jerk-like behavior.
Yes, developers should listen to suggestions and try and weed out the wheat from the chaff... But why make that harder for them by adding all that extra chaff? Don't you want your ideas to be taken seriously and on their own merits? If that is the case, it is best to make it as easy for the receiver as possible.
You also have to be prepared for honest critical feedback. Like the ideas being presented, feedback should also be accompanied by clear data or references to back them up. That's called a discussion or a conversation.
Persuasive arguments are ones that keep the audience or reader engaged and invested in the material being presented. This is especially the case when those being persuaded own and control the things about which those ideas pertain.
I think that Vincent Parrett is capable of accepting and understanding such feedback in the spirit in which it was given.
I agree with all of that. I do think though that Vincent already presented suggestions that had barely any chaff. From my perspective on the outside, it's wearing to be met with resistance when making suggestions, even when you do an excellent job, as Vincent did, of making the suggestions. He spent loads of time writing and honing that post. For Marco to pick up on such a small part of it was what upset me.
ReplyDeleteDavid Heffernan In Marco's defense, there has been a long history of nearly abusive behavior among certain elements of the customer base (especially from those that haven't paid for a product for over 10 years). Some of that experience has certainly made for some very raw and visceral reactions.
ReplyDeleteIt's like touching a raw irritated sore... normally, it wouldn't have been a big deal, but since it is already irritated and somewhat raw, reactions may be a little heightened. Especially given the challenges they currently face with the new management. That's not an excuse, for sure... but an explanation all the same. I suppose your reaction can also be attributed to the same thing, no?
Vincent Parrett's post certainly wasn't even close to any level of jerkishness (yeah I made up that word ;). I was just pointing out that it could be even better. Had it risen to what I would consider any level of jerk-dom, my response would have been far less helpful and measured.
Allen Bauer Darn... I would feel much better if I could pester you about Swift...
ReplyDeleteDalija Prasnikar You can certainly try... however, I would likely agree with you on most things :). And where is the fun in that?
ReplyDeleteAllen Bauer I am sure we would find some topics for disagreement ;-)
ReplyDeleteVincent Parrett If you can't tell the difference between a mature eco system and a startup ecosystem then you must be, but surely you can?
ReplyDeleteJeff Dyer C# is a "startup ecosystem"? It's 14+ years old. At what point does something become "mature"? And does "mature" mean no more change? Vincent Parrett has every right to make suggestions.
ReplyDeleteThe tone of your original comment and this one certainly comes across as condescending and elitist. Was that your intent?
Jeff Dyer WTF are you talking about? C# is hardly a startup eco system. C# 1.0 was released in 2001. https://en.wikipedia.org/wiki/C_Sharp_(programming_language)#History
ReplyDeleteAllen Bauer Yes, probably I've got a few festering open sores
ReplyDeleteMarco Cantù I don't see the need to sugar coat things.. believe me, I rewrote that opening paragraph several times to tone it down somewhat... perhaps I just say how I really feel?
ReplyDeleteI let my software assurance lapse this year, we are still using XE7 here, I could not see any value in upgrading my code and all the third party libraries past it, when most of the changes were for mobile support, often to the detriment of the desktop support. When I install a new version of delphi, the first thing I do (after fixing my environment path variable yet again so windows keeps working) is to diff the rtl and vcl source code. It's not nice to see some changes that look like they were written by interns.
I do feel that there was a throwing out of the baby with the bathwater to some degree, the focus on mobile has been at the expense of desktop developers, and there is a perception that desktop developers being milked to keep the mobile dream alive. Perhaps that's just me?
I could go on venting like this for hours , but it would be a waste of time.
I posted what I though was a constructive post, providing a topic for discussion, without venting.. and the sum total of your response is to complain about (what was a very small) criticism of the product.
I have other posts about the package manager, IDE etc, I don't think I'll bother finishing & publishing them.
> and the sum total of your response is to complain
ReplyDeleteNo. I wrote multiple times I appreciated your blog post and its content. And I sincerely believe it, as it is a valuable blog post for us and for the community. I mentioned a criticism (which I don't think it merely an opinion), and you are right in saying "perhaps I just say how I really feel". I do understand you feel the language hasn't evolved enough. Point taken.
Vincent Parrett whatever. My point still stands. I was programming in pascal in school in 1983.
ReplyDeleteJeff Dyer Your point might still stand, but I still have no idea what your point is. sigh
ReplyDeleteVincent Parrett obviously. Sigh.
ReplyDeleteVincent Parrett I suppose my point is that even in 1999 delphi was a mature productive platform and adding features to catch up with something a generation newer is to miss it's clear benefits which is clear, simple syntax that developers of all levels can get into quickly and productively. Which is the whole point. If you want linq and other anonymous method stuff, fair enough, but there is nothing you cannot do in delphi already. Never heard of the workman and his tools?
ReplyDeleteJeff Dyer You should have led with that statement instead of just assuming everyone understood what you were talking about and where you were coming from.
ReplyDeleteI, and probably many others, don't necessarily agree that evolving the language somehow negates those key benefits you cite. New and productive enhancements are possible without affecting the existing stuff.
If that is not what you meant, please clarify. Otherwise your statement sounds a little curmudgeonly and borders on "get off my lawn!"...
Jeff Dyer I think we just want some sharper tools, which make it easier to perform our craft. :)
ReplyDeleteJeff Dyer Well as the author of several popular frameworks for delphi, I'm going to call BS on that. Try doing auto mocking without generics, since we're talking about 1999 you can use Delphi 5, let us know how you get on. Or try something more advanced, like reactivex.
ReplyDeleteIt's this head in the sand don't mess with my language it does everything I need that annoys the crap out of me. I can do everything just fine with ones and zeros thank you.
Martin Sedgewick to my mind software development is about understanding the problem and having the skills to implement a solution. Adding bells and whistles to make your programs more complex just because of fashion negates that.
ReplyDeleteJeff Dyer Do you not think that one can do both? Understand the problem and use the latest tools at one's disposal to implement a solution?
ReplyDeleteHmmm... let's see... I need to cut that log... I could use that new fangled gasoline powered chainsaw. Nah! I'll just grab that stone axe and chop away.
Jeff Dyer I'm slightly surprised you ever got over the shock of exceptions, RTTI, classes and metaclasses and other such 'fashionable' fripperies... Procedural Pascal forever!
ReplyDeleteVincent Parrett Thank God (is that you in this case?) for DUnitX and Delphi Mocks!
ReplyDeleteMartin Sedgewick Lol! no, I'm not a god, maybe just a legend in my own mind (according to my daughter!).
ReplyDeleteVincent Parrett Probably a legend due to the amount of time you get to spend with her now you no longer need to hand crank mocks :)
ReplyDeleteAllen Bauer "those that haven't paid for a product for over 10 years" can go both ways: we paid (subsided in effect) multiple licenses up to XE6, despite being unable to upgrade from XE (which we still use), because of a variety of bugs and regression in IDE or RTL, and we just had no time to devise workarounds against those, and there were not enough improvements to warrant the effort (and some scarecrows, like zero-based strings, which cast severe doubt on the viability of Delphi as a platform for us).
ReplyDeleteWe let lapse most of the license, but still made purchases XE7 & XE8, just for trying (none of which brought enough benefits). Of all those versions, the only one I still have installed are XE2, which is used for some 64bit utilities (but whose 64bit debugger proved to troublesome when working on larger projects), and XE8, which I have not started in months.
And we even had to write a procedure detailing the XE (re)install, to remove all the crashy-prone IDE modules (error insight, etc.), installing IDE Fix Pack, etc. which is NOT time well spent. I would rather we could use error insight and editing tools in Delphi, like you have in pretty much all other IDEs.
That's all money that went down the proverbial drain.
So that comment of yours about non-paying customers just resonates as whining TBH: you still got paid all those years, we spent time and money for nothing.
/rant off
Eric Grange I didn't intend to lump everyone into that category, nor make a wide generalization. There are many customers who go on and off subscription according to their needs. In my mind I was specifically referring to those that have for whatever reason remained on D7 or D2007. Hopefully the low- or no-cost options can alleviate much of that.
ReplyDeleteThe facts of the matter are that the stand-alone tools business exists on razor thin margins. That means the development teams are stretched very thin. There aren't massive subsidizing products such as an OS, productivity tools, hardware, cloud or services organizations. In those cases, the tools are considered "enabling technologies" and value added. Yet the density and breadth of the required technologies to remain competitive are the same, if not more so. The talent required to produce the product cannot be some mid-level group of developers. You need folks that have a deep knowledge and understanding of how to produce tools, not merely use them.
This isn't an excuse, just the reality. This is precisely why the development model at EMBT has shifted drastically... It remains to be seen how this will play out.
One thing I've learned very quickly here at Google, is that in retrospect, it is flat out amazing how the team at EMBT did way more per dev than many of the folks here at Google. That's not to put down the developers here at all, rather, it is to highlight that even though there have been some struggles, on balance, they did (and many still do) amazing stuff with the resources given.
Since leaving EMBT, I've only gained more respect for those that remained there and are working even harder to keep the product viable.
Even here at Google, we find serious bugs in the tools we use. Many of them are massive productivity killers. However, the reaction to such issues are never that of hand-wringing and angst. The first reaction is "how can we avoid the problem or work around it" and "to whom should the bug report go?". Sometimes it's and internal infrastructure team, and sometimes it's an external tools vendor.
Allen Bauer I get you on productivity per dev (or per whatever) at the larger corporations, especially those with an expanding market. But thin margins can be common in smaller corporations, or those that have no massive VC injections (but those can go down even faster than they went up).
ReplyDeleteThe reactions you describe about working around issues and then reporting the problem is common all across the industry, but the implicit requirement is having someone respond on the other side, then it can get in a real relationship, and no angst arises (or limited angst). This is something most of us in the IT industry have to deal with daily. If we look at all our products here we have bug reports coming in daily, and we have bugfixed binaries released regularly, and all kinds of script-based releases for specific projects pretty much daily. It's all a dialogue. New deployments see more, older deployments less, but there is always a flow.
Problems arise when one side ignores the other, exhibits "we know better" attitude, or takes the "if you are not with us, you're against us" stance, then things do go sour.
If there are problems (there always are), clarity and openness goes a much longer way than (ofttimes aggressive) denial. I am not aiming at you there, but there was plenty of such from Borland/Inprise/Embarcadero (yes, I am exempting CodeGear from the list).
Have you noticed that the whole R&D staff has been fired? Who should implement that?
ReplyDeleteAllen Bauer He, he, he... so comparing to Google Embarcadero seems to have small team....
ReplyDeleteWhen you wake up in the morning with pounding headache and you are all "Darn... half of my think tank is disabled, maybe my left hand and my right hand can work something out in the meantime...", then you are working with small team ;-)