440bx: your answer doesn't really concern how much syntax is enough.
Most important, it isn't about syntax. It is about having constructs that express often encountered logic flow efficiently.
Yes. But I have serious concerns with the "often" of that argument. And if it is not often, it can be better made with combinations of existing logic, instead of having larger, mostly unused constructs.
As Rainbow6 says, very complex nested ifs are not that common in Pascal code. (in Verilog, however....). I share his experience (from working on car auctioning site) that such discount schemes, pricing etc are usually stored in sql tables and not hardcoded in code.
I nowhere have complex nested decision trees in my code.
How many different ways must there minimally be to do the same thing?
What a loaded question! The answer is, as many as it takes until you find the simplest and optimal one. That in turn implies there is a road to travel to get there.
As loaded as the message I reacted to that talks about "Serious omission", when it is the first time suggested in 25 years.
If someone were to apply the hidden premise present in your statement which is, anyway to do it is good enough and justifies not searching for better ways then, we'd be still be doing Algebra using geometrical shapes and, using that method, it is very doubtful we'd enjoy the pleasure (and aggravations) of having personal computers (among many other things.)
Yes, but I fail to see how to connects to this problem. People don't switch to programming only using evaluate statements (and frankly, they are welcome to Cobol if they want to)
IOW your suggestion is more because Euclidian proofs of algebra had some merit, everybody should always lug along his set of golden geometric rulers and polish them three times a day.
Maintenance of language costs effort. Seldomly used constructs are therefore not good candidates for inclusion.
Reasoning like this only leads to baroque languages.
On the contrary. It is your reasoning that leads to the enshrinement of "less than optimal" constructs. Just because you can make them work if you stand on your head and wave to a penguin 1800 miles south of Mecca doesn't mean it's good enough. Most people would consider that a "suboptimal" solution even if can get the job done.
I'm sure there are linux users in Saudi Arabia nowadays :-) Somewhere somebody has a phone with a penguin. Try waving a fish otherwise :-)
Free Pascal dialects is already way too large from language design perspective. Some is compatibility, some extensions to do everything (from embedded to enterprise to own RTL to native windows).
That is true and, it is often the result of the desire to achieve some goal, such as Delphi compatibility, which may have originally been worthwhile but becomes dubious with time.
I don't agree. It will become more important than ever. When people desert Delphi, a close relative is easier than a far away. You'll never get all (or even most) of them, but increasing artificial barriers won't help.
Stronger even. If I had my way, I'd abolished the mostly redundant FPC and OBJFPC modes 10 years ago. The only thing worse than having a bad language construct is having a bad AND a good replacement for the same construct.
It is something else however to constantly keep adding redundant constructs because of heated plea on the forum and some nicely formatted concept code.
I definitely appreciate nicely formatted code that reflects the structure of the language but, a multi-branch construct has nothing to do with formatting, it has everything to do with function. That said, just like any other construct, it is much nicer to see it well formatted than otherwise.
It is easy to make a case seem compelling with an example where it actually saves some chars and looks somewhat ok. It doesn't mean that that economics example is the expected average situation.
So let's reverse the question: how much is enough according to you?
That question can be answered but, not in a few lines. To give an example of why, I'll apply your question to the field of Mathematics which gives, how much Mathematics is enough ? the answer is not obvious and it greatly depends on what it will ultimately be applied to.
Well, I want you to put yourself in the shoes of a custodian of a programming dialect, and try to come up with rules what is logical and what not. You may even use Mathematics.
It's important to be choosy but, that's a different thing than always being against everything. 
There is definitely "baggage" in FPC but, that should not be used as an excuse to get in the way of improvements.
People that want something always call it an improvement. If you are the only one in 25 years, there is a good chance it isn't
Recent
