It was a nice try but I reckon you are pissing in the wind.
Mr Nick Hodges of CodeGear and Embarcadero and not Borland blogs amusingly about the obscure corners of Delphi syntax. Delphi Pascal apparently still implements a Jensen and Wirth era feature whereby [square brackets] can simulated by the sequences (. and .). In the olden days, MyArray := 0; could look like this (assuming …
I love Delphi dearly. I almost named my cat Delphi. But Delphi died a few years back. Anyone looking to rewrite project will use C# rather than grapple with a Delphi language reboot. Sad but true. Microsoft care about their product far more than codegear do.
Incidentally, I agree with not needing a garbage collection. Whenever my cool Java using colleagues mock my Delphi love, I hit back that real men don't need garbage collections unlike their pussy language. Gets them every time. What is does need is a string object with built-in methods. Using procedure string operators just feels too retro these days.
Some good ideas on that list but, as a programmer who has had to move between C/C++, C# & Delphi a lot over the last 15 years, please god don't mess with case sensitivity and the with operator.
Being case sensitive, and not having an equivalent operator to with, in any of the C variants is the biggest pain in the ass of having to use them. Anyone who thinks Delphi being made case-sensitive, and the with operator removed, has obviously not used Delphi a lot and wants a slap!!!
I would prefer to see case insensitivity left in - the number of times I have seen several variables and types all same but different case (upper, lower, camel and pascal cased) can make it a real pita trying to work out which one it is referring to - especially in these days of unit tested code - where some coders seem able to put 10 layers in to do 2 lines actual "work" code - so quickly scanning code it isn't always obvious that it isn't the local variable
Garbage Collection - I'd agree leave out - I have encountered bugs that are related to coders thinking they don't need to clean up - which might be true or internal objects, but not true of OS resources
I'd love to see them keep Delphi/Object Pascal alive and progressing - but it looks very like life support is failing :(
Verity, you ask my opinion? I think GC is a good thing, but if customers don't want it, then customers won't have said feature forced upon them. They do pay the bills, after all.
Most likely, precise collecting GC will be made possible through enhanced RTTI, but not enabled by default and very probably even without a collector in the box.
As to your other points, I don't want to speculate, and in any case this isn't the right forum for hashing out those kinds of decisions. I do want to stress, however, that whatever we do, we have backward compatibility with existing code uppermost in our minds. Creating a clean separation between a spruced up language and bringing along all the existing code is at least half the work involved.
If I wanted a C# or Java, I would use it and not Delphi.
IOW, I use Delphi because it is not C# and Java, most notably no unpredictable and resource/lock hungry GC.
Also one could argue that case insensistivity is the natural state: a word in natural languages means the same capitalized or not. So unless you want to add shouting as a language feature I don't see a reason to make a language case-sensitive.
The rest is more a matter of taste, but again, I'm using Delphi because of them now. I like being able to see the declaration of a class without micromanaging folds, or what variables a procedure uses. The IDE helpers already mitigate the extra typing for a decade.
Personally, I don't see any feature that interests me in this article that I like. The stuf I'd like to see in Delphi is way simpler, if I HAD to pick language features, it would be bitpacked records (interfacing hardware here and there), generics based on true value types.
What kind of primitive person are you? Should we get rid of GUIs too?
Here's a different idea, although I realize it doesn't concern very much the main target group of developers for Delphi: Compiler Optimizations! I'd rather not have to learn C++ so I can write floating-point stuff like synthesizers and audio effects that actually perform roughly as well as a C++ implementation. Maybe even some SIMD goodness?
I used Delphi for a while many years go - I quite liked it, but it had one HUGE drawback - it's Pascal.
Pascal - possibly the worse high level language ever conceived, which is a shame because I spent some time having to write stuff in it (not in Delphi though). It's inconsistent in its syntax. The syntax it DOES have is horrible. It's ...urrrggghhhh.
As for C# (as it has been mentioned), I just don't see the point of this other than to tie yourself into Microsoft's platform.
Java - Mmmm.... probably best I stop there.
At the end of the day, whatever they do, Delphi is still always going to be a variant of Pascal. Named after someone who wasn't smart enough to realise that believing in the wrong god would be more likely than not believing in any of them to piss the right one off, Pascal was originally invented to be a teaching language; and the whole point was that you weren't supposed to be able to do fancy stuff with it. If it was a car it would have one pedal, no gears and a non-removable big red learner sign. Turbo Pascal (which eventually became Delphi and Kylix) just added some -- alright, a lot of -- extensions to make it into a usable language; but really, it was still Pascal underneath. I'm not sure that your enthusiasm isn't a tad misplaced.
Seriously, just learn another language and get on with it! If you don't like Java, you will like Python even less; but Perl's got plenty of life left in it yet, whatever a small vocal minority of detractors with vested interests in pushing their own agendas may be saying. And, of course, the kind of regex support others can only envy .....
Grammatical gender is even worse than you realize. Lots of languages have "gender" that is not based on sex, for example a west African language that classifies nounds as "human", "animate, not human", and "not animate". [Slap a big IIRC on that.]
Other languages have many more genders than three.
And even languages with ostensibly sex-based gender have irregularities and are to a large extent arbitrary: just cross the Channel to France or Germany.
As for case sensitivity, what do you do about a language like Georgian which is written in a caseless alphabet? (It has, however, three or four distinct forms of that alphabet.)
Some good ideas there, especially getting rid of with and not implementing FOTM GC. But, I definitely don't want case sensitivity in my favourite language.
Surprised no one has mentioned the mistake in your try.. finally code snippet yet. Object creation should happen before the try statement. If something goes wrong in the creators your code would attempt to free something that does not exist in your finally section.
I used to use Delphi but never really warmed to it.. I agree with some commentators that case-sensitivity is junk but as the big V says, we do have to work with systems that are. Sensitive, that is. So, being insensitive is. Insensitive, I mean.
I used to read .exe at university (it was free in the library) and the best bit was Ms Stob. And now she's the best bit of El Reg. Ace.
Case insensitivity is A Good Thing.
Case sensitivity is insanity when it comes to programming languages, and suggesting it exposed a contradiction in your own pecadiloes....
On the one hand you dismiss the separate interface/implementation sections as flawed and point to the need for IDE support to make it workable as evidence of those flaws, and then invoke the wonder of IDE support to make case sensitivity more workable.
Just because everyone else in the room is smoking does not make it A Good Idea to take up smoking.
You also reveal a slight lack of familiarity with Delphi as IDE tools for not only navigating but CREATING missing interface/implementation declarations have existed for many, many versions already.
Ctrl+Shift+Up/Down will navigate between interface/implementation
Ctrl+Shift+C will complete the declaration of the type under the cursor
And without separate interface/implementation, further IDE support is needed to make code browsing and navigation an acceptably efficient - and dare I say pleasant - task. The lack of separation between declaration and implementation in C#/C++/Java is the principle reason that code created in those languages becomes intensely difficult and cumbersome to navigate.
Sure it makes it "easier" to CREATE code but code spends a far greater time merely existing and having to be maintained than it does being created.
Similarly the lack of clearly defined declarative areas for variables and the like.
You stumble across some code using some variable - it's type may not be immediately apparent to you (sidebar: type inferencing is great for compilers who have the gift of perfect knowledge at compilation time, and a real PITA for developers having to MAINTAIN code created in a whimsical nano-second of creative joy, but which then has to sit around being maintained and understood for years after that not-that-much-more-brief moment of labour-reduced intensity) .
With the ability to declare variables whilly-nilly and hither and thither, where is the poor maintenance developer to go to seek out that declaration? They have to go spelunking (or invoke yet more IDE scaffolding).
I agree that garbage collection isn't a good fit in Delphi. But there are occasions when the compiler could be coerced into taking the drudgery out of our miserable existence as developers without involving the overhead of reference counting.
Some time ago I suggested co-opting the existing but now long since out of use "automated" keyword to mark a local variable (of object reference type) as following the interface type semantics.
list: TList automated;
list := TList.Create;
The "automated" keyword would simply direct the compiler to:
- initialise the variable as NIL
- call "Free" using the object reference when the variable leaves scope
Currently interface reference type variables follow an almost identical pattern:
- initialise the variable as NIL
- call "_Release" using the interface reference when the variable leaves scope if the reference is non-NIL
(note that for object references the non-NIL test is redundant as it is handled by the implementation of Free, which is already NIL-safe - this is not the case for interfaces)
The same approach could be extended to member variable declarations and, less usefully but for consistency, unit variables (so called - incorrectly so - "global" variables).
This small change would make an immense difference to everyday programming jobs, but equally could be completely ignored by those who enjoy creating try/finally constructs.
There's lot's more that could be said, but suffice to say at this point that for a "dead" language, Delphi seems still to be doing a lot more than just twitching.
There are 52 letters in the alphabet, not 26. The letter "a" has as much in common with the letter "A" as the figure 4 has in common with the dollar sign. Once you get to thinking more like a computer and less like a human being, you will understand why case sensitivity is the natural state of things.
Codegear - or whatever you're called this week - just don't listen to this.
Yes, by all means, please fix the unfortunate case sensitivity issue with the Register procedure, but how can you take someone seriously who doesn't know that Win API DLLs have their APIs in upper case and tries to use that as an argument for making Delphi case sensitive!
Or doesn't know that you can move from a procedure to its implementation as easily as pressing shift-ctrl-down? Or has never used the fab code refactoring tools in the newer versions?
Or wants us to write hideous long identifiers when a carefully applied "with" statement can improve productivity no end. The verbosity of C++ drives me bonkers!
If you can't be bothered to learn good engineering practices, go write in VB. We don't need the language to dumb down to bad practices.
Don't get me wrong, I also agree with many of your assertions, but this article is just too full of ill considered guff to be taken seriously. I have to write in C++ a lot in my job, but on the odd occasion when I get to write in Delphi my productivity improves hugely. And much of this productivity increase comes from just the things that you are wanting to change.
No, it's more like defecating in the tornado :)
I see absolutely no point to invest efforts in something as useless as pascal/delphi always was and as lifeless as it is today. Probably, it could make sense if you add some conceptually new/revolutionary features to the language, otherwise you'd better help improving something more useful like e.g. python/ruby/haskell.
P.S. Especially given The Current Economic Situation
Good points, but (unless I missed something, and I'm too lazy to re-read it) you didn't touch on my one big gripe with Delphi, the annoying insistence on having to specify:
type_inst := type.Create();
Or somesuch. What's wrong with:
type_inst := new type;
I have hardly ever come across a situation where the constructor is anything other than Create() or an overridden version ...
Two comments. Firstly I wrote a complex timetable planning application in 1983 using UCSD Pascal - this application was constrained, not by the language but by the hardware that it was running on. But perhaps you are too young to remember real Pascal?
Secondly. "case sensitivity is the natural state of things". If that was the case you shouldn't be able to read ThIs LiNe BeCaUsE iT iS WriTTen iN mIxEd CaSe? Codswallop!
Well there are 255 characters in 7-bit ASCII, let's have all of those in variable names as well.
Anyone who thinks that, for example, aVariable, AVariable, AVARIABLE, avariable, aVariAble etc are all sensible and adequately differentiated names for *different* variables should not be allowed near a keyboard, IMHO. Or should be forced to only program in fortran-66, where they aren't able to hurt anyone.
Heresy to invoke VB in this discussion, but defining the case of a variable in the declaration, then the IDE converting all instances of this variable to the was it is cased in the declaration = very good.
Interesting article, but, and I hate to have to say it, you don't know the IDE that well :(
Firstly with the class declaration in Delphi. Once you've typed your function into the class declaration in implements, press ctrl + shift + c. It auto completes the definition in the implements section and then ctrl + shift + down will move you down to it (and pressing up will move you back to the declaration).
Secondly (and here we find out if html tags get through the filter) [b]with[/b] is a useful tool for shortening excessive lines of code. None of the wonderful times where you can't read the line because it's so far of the right hand side that you have to keep scrolling to see what it says. If it's used correctly it's a useful tool, but as ever with tools you don't want to see them in the hands of an amateur.
Next, try finally. Finally is used to execute code that will always be called even if an exception is called. Most people use it for 'cleaning up', but it can be used for logging messages etc of the code pass or just shutting file handles so they don't get left open. Delphi has, built in, a form of garbage collection. Locally declared (to the procedure / function) variables are automatically disposed off when you go out of scope. And then again there's interfaces. I'm sure your aware of how the ref count works on them.
The new keyword is a copy of the reintroduce keyword that overrides the inheritance so that it does complain about visibility etc. If your just overriding a procedure and you don't want it to do the inherited code, leave out the word inherited from the procedure.
Case sensitivity is a major way of screwing up a program. I've seen (having programmed for 14 years now in ASP, ASP.Net, C, C++, C#, Delphi, Java, Informix 4GL, Visual Basic and VB.Net) the same variable being used with slightly different case changes which lead to some wonderful confusion by the guy who wrote it (not me) when he had to fix a bug two weeks later and had forgotten which case meant what.
Lastly your complaint about const. Const is used the same way as #define in C. You define a named constant to represent a value so that if you use it later or change it at a later point, the value is only kept in one place. You don't have to use it, but it makes it a lot easier i.e.
LinesPerScreen = 20;
then LinesPerScreen would be used through the code and if we wanted to add more, we just change the one line and not the 50 references throughout the program.
If you wanted you could always declare it as a variable and then initialise it in the initialization section of the unit just to avoid const.
If you want a good change to const, try doing const x : integer = 1; and then using it as an array parameter. That is another thing that needs fixed and it's legacy to Delphi 1.
Apart from that an interesting read.
Delphi already has the exact same thing; it's called reintroduce.
Normally, if a subclass redeclares a *virtual* method without overriding (possibly also changing arguments), the Delphi compiler issues a warning because you are hiding the method in the ancestor class. By adding the reintroduce directive to the decalration, you can suppress the warning.
NOTE: If the method that you are 'hiding' is not virtual, then there is no need to provide a warning, because you are not impacting polymorphic behaviour.
Delphi provides the warning because it is DANGEROUS to hide a virtual method. It creates a situation where the implementation of a method that is invoked is no longer dependant solely on the class of the object for which it is invoked (the whole POINT of a virtual method); but is now ALSO dependant on the type of the reference to said object.
Moreover it is never necessary to hide a virtual method. Every example ever demonstrated to me could always be very easily rewritten to avoid the ambiguity.
In fact I classify "reintroduce" in the same category as "with". I would like it removed from the language; and for Delphi to report an error, if ever a virtual method is hidden; not merely a warning.
Have you seen the prices of the Delphi products. No way will any student or teacher ever buy these so no new blood will be recruited into the Delphi family. Maybe they have a good education and student discount scheme but I saw no obvious evidence of this on visiting their site. Even Microsoft have free versions of their programmer's tools to lure in the newcomers.
Actually, Verity's try..finally snippet is not flawed in the way that you think.
He has preinitialised his variables to nil before the try statement; therefore FreeAndNil will not attempt to destroy something that does not exist.
I agree that the normal convention is to Create before the try statement; however, Verity's convention is the only way to correctly support multiple objects protected by a single try..finally construct. Using the convention of construction before the try statement, you would have to nest multiple try..finally constructs, or face the risk of memory leaks when one object is created successfully, and the next is not.
Turbo Delphi Explorer is available as a free download. It is a based on the earlier Delphi 2006 version with some features cut. Current Delphi version is 2009.
Before you ask for this and that in the free Turbo Delphi, please note that MS also limited C++ native code development in Visual Studio Express by NOT providing MFC.
Maybe. In '83 I was picking up bad habits in BBC BASIC (though not as bad as the habits some people were picking up with Microsoft BASIC) and getting ready to learn 6502 assembler. I remember Pascal as having (1) lousy string handling and (2) ordinal types, which my lecturer raved about; similar to an ENUM in SQL but you couldn't actually print them out.
Perhaps the UCSD implementation of Pascal was especially good, or maybe your application simply didn't need anything it wasn't offering.
And whilst I agree that calling variables foo, FOO, Foo, and fOO is a bad thing, that's why we have capitalisation conventions. "foo" is a variable we're not exporting, "Foo" is a variable we are exporting, "FOO" is a constant and "_foo" is a variable that we are exporting but only under extreme duress.
I first ran across UCSD Pascal at Ford Aerospace in late 1980 or early 1981 ... It was implemented as "The UCSD P-system" on half a dozen pilot build IBM PCs ... Actually, it typically ran on two of them, three ran PC-DOS, and the last ran CP/M most of the time, and the built in ROM BASIC occasionally. All 6 sucked. So I guess I can say I've been dabbling in Pascal for nearly 30 years. To date, I have not found a single project that wouldn't be better implemented in another language.
As for case sensitivity, I agree with A J Stiles. When you boil it all down to ones and zeros, an 'a' is NOT an 'A'. Folks who understand this, and understand how their compiler works, can do some amazing tricks. Not that anyone cares how compilers work these days ...
ANYway, it sounds to me like Stob wants to learn good ol' K&R C :-)
Sure, I would rather write with C# and the shite hole called .NET than use Delphi in native Win32.
Granted there is a Delphi .NET option... CodeGear needs to die for this...
And before anyone says something, Xenocode is a retarded solution.
It does if you run code in the Create() procedure of your own classes.
Why bother changing the syntax, isn't this really the main difference between other languages? And as for Delphi being dead, I still see loads of code being released in Delphi.
They just need to reduce their ridiculous prices now.
Biting the hand that feeds IT © 1998–2019