Learning Delphi

[Keesver 23]

Hello,

 

We extended our team with new (inexperienced) developers. What would be the best way to teach them Delphi?

 

Greetings, Kees

[bazzer747 25]

A great place to start is  LearnDelphi.tv  Lots of free video's to view, but the paid for videos look at the details of all components in the VCL.

[KodeZwerg 54]

3 hours ago, Keesver said:

Hello,

 

We extended our team with new (inexperienced) developers. What would be the best way to teach them Delphi?

 

Greetings, Kees

1. Hire a freelancer that teach

2. udemy has good learning courses, not free but worth the invest.

(a free solution can be youtube, with proper search input you get okay output)

 

Mix of both should be best practice.

[Dalija Prasnikar 1404]

Generally, books are the best resource for learning any language. More experienced developers can usually get they way around new language faster, so official documentation might suffice.

 

Anyway, Delphi Language Guide is always a good place to start http://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_Language_Guide_Index

 

[David Schwartz 430]

Of course, there's also Marco's latest book. And even stuff like old Delphi 3 and 4 books would work for covering the basics (just don't look at the screen-shots!).

 

Are they new to programming? Or just new to Delphi? 

Edited April 3, 2021 by David Schwartz

[Keesver 23]

New to Delphi, they have completed their bachelor's degree in software engineering.

[david_navigator 12]

Depends how much you want to invest (time & money).

When I on boarded a new (to programming) developer many years ago, I started off by giving him small project to play with, searching through books/Google gave him the info he needed to write the code, but it was sometime after that I realised that there were fundamentals about developing code missing from his knowledge e.g he had no idea that the concept of break points & watches existed, so was littering his code with showmessages when trying to debug.

[bazzer747 25]

In the early days (Delphi 3 and up), I bought every book there was and they really helped. Much better than online documentation. However, over the years I used them less often and eventually (under pressure from other half!) had to get rid of them. Space was the issue, plus I looked at them less frequently. I regret that now.

Most of the Delphi books out there now are generally quite advanced and very expensive.

[David Schwartz 430]

On 4/3/2021 at 2:27 AM, Keesver said:

New to Delphi, they have completed their bachelor's degree in software engineering.

Right out of school ... it will depend what they were exposed to in school. They probably understand OOP and OOD, but may not have much experience with strongly-typed languages like C/C++ and Pascal/Delphi. 

To me, after 40 years, most imperative languages all look the same, except for added things for stuff like vectors, parallelism, and more esoteric stuff that all tend to be language-specific.

 

The latest feature that most languages are adopting is the use of "attributes" on classes and class members. I don't know how Delphi's stack up against any others, but it may be worth discussing.

 

Other than that, what I'd call the "dynamics" are going to be a big part of what can hang them up. 

 

For instance, Delphi has added some interesting features to the language like for...in that make using various kinds of containers a lot easier. But there are things missing from Delphi that make it impossible to use some of these newer features at times. For...in is great unless you need to refer to the index or position of the selected item in the list, for example.

 

The lack of a trinary operator means there are lots of if...then...else statements that could be collapsed into a much simpler trinary expression. There's the IfThen method, but it evaluates both arguments before choosing one, which makes it useless when trying to avoid referencing null pointers. Most contemporary languages accomodate both of these things today, so it might seem confusing in that respect. (Delphi may support it in an upcoming release as part of NULL expressions, but a trinary operator could have been introduced in the languge way back that simplified it forever.)

 

The RTL has been extended using class helpers to mirror a lot of stuff commonly found in C# today. Class helpers seem like a hack to me, but they do let you introduce new methods into a class without having to either modify the class itself or subclass it. Unfortunately, they're not inheritable, which seems really strange to me (and probalby newcomers as well).

 

Most contemporary languages also support case statements that take strings as discriminant variables, but not Delphi. This gives rise to maybe a dozen different ways people work-around this missing language feature that's only missing for little more than "religious" reasons.

 

Initialization of arrays, lists, and objects in Delphi is something that isn't often consistently applied within and across projects, so make some clear recommendations. (Good Idea for a Coding Style document.) In particular, if you have a list of Enums, there's a common practice of prefixing them with a couple of letters so you know what class they belong to. This prevents simple use of RTTI to get a string representation of their name to display at run-time. So you need a second array of names and a lookup function for that purpose, although I've seen slightly more elegant ways of doing it that escape my mind at the moment. (To me this sort of variable-name-to-string-name mapping should be a fundamental language feature of every programming language ever written. In practice, few if any offer anything at all.)

 

This stuff can be really confusing to people familiar with what other contemporary languages offer in their place.

 

So I'd say give them a lot of "bread-and-butter" type code to write and do a lot of code reviews to suggest alternate ways of expressing things to expand their understanding of the language and RTL.

 

If you're having them build UI-based apps, try to instill some good coding practices, like avoiding putting logic into Event handler methods. It's so easy to do, right? For example, the presence of an Add and Edit button on a form might lead to two almost identical methods, one of which might initialize stuff from one set of vars while the other will initialize with constants. And to allow a "Cancel" button, you probably need to track whether you're in Add or Edit mode. (Forms that use DB-aware controls can handle this directly.)

 

One thing that I personally find quite ridiculous is the fact that most Delphi programmers don't treat interfacing with forms the same way as other objects. For reasons going back to Delphi 1, Delphi allows the programmer to reach directly into forms and fiddle with local variables and even fields from methods inside of the client forms (which are bona fide objects!) using with them, where nobody in their right mind would do the same thing with normal objects. I see very few Delphi apps that do this consistently and what I'd say is "correctly". Again, I think this gets into more of a "religious" debate, but if there's not a lot of consistency in how it's done in your projects, a new programmer is going to naturally ask "WHY?" and be rightfully confused over something that really has no excuse other than the programmers were lazy.

 

Finally, keep on the lookout for use / abuse of global variables.

As far as learning the language itself goes, I'd say any old Delphi book from D4 onwards can be used as a guide for most things, except the screenshots of the IDE. Newer versions have more methods in older (ie, "classic") objects than are found in older books, but what's there is pretty much all still 100% valid.

 

I'd also be tempted to give them some exercises to learn all they can about TStringList. It has always been one of the objects in the RTL that I've used the most over time, and they seem to keep adding new functions to it with every Delphi release.

 

This is what comes to mind in a few minutes. There's probably a lot more.

 

Edited April 4, 2021 by David Schwartz

[weabow 6]

VCL or FMX ?

[Keesver 23]

VCL and FMX and Oxygene (much of our code is reused in our web application using WebAssembly)

 

Edited April 6, 2021 by Keesver

[Keesver 23]

Thanks everyone for your comments. Enough information to look into.

The Delphi language guide looks like a good starting point, this is something the person can do by themselves.

 

@David: your comments include a good list of topics that need to be touched in the learnings. 

 

Greetings,

Kees Vermeulen

 

 

[weabow 6]

On my opinion, FMX is tricky, and not stable. From one version to another, things change. Right now, my position is that if I can go on deploying crossplatform, I DO NOT UPGRADE Delphi.

 

It looks like VCL, but it is not. I've bought some help, and I can say now that I wouldn't succeed without it. But my app runs on Windows, Mac, IOS, Android and Linux.

[Guest]

@David Schwartz, nice neat write-up!

 

Is that something you have in your back-pocket or did you just type from the top of your head?

 

Either-or, it became a very IMHO pertinent guide into Delphi's quirks.

Then, being first and formally an educator, there are all the quirks from other langs/environs that people brings into the D-word for no reason what so ever. I'd like to see a similar concise writeup about all those pitfalls 🙂

 

Thanks!

[weabow 6]

Well, its's not difficult for me to give examples...

 

Pb with timeout on Internet connexions (doesn't run crossplatform),

Pb with inheritance with styles : need to set style at each level,

Pb with SQLite drivers : from one version to the next one, no way to have prepared queries ; need to insert values inside SQL, on some platforms only (was running fine in previous version),

Layouts : from one version to the next one, objects do not appear in same order,

JSON : from one version to the next one : some responses no longer come back, even if the key exists, due to the insertion of quotes in FMX source code, (no need to speak about memory leaks too...),

Deployement : from one version to the next one, even if Apple didn't change its strategies (be careful), splash screens change their sizes and positions from one boot to the next one (was running fine), also in Android,

And so on.

 

If you want to see some bugs, just go to https://quality.embarcadero.com/

 

What I want to say here is that Delphi is not better nor worse than others languages. But it would be a lie to say that it's perfect.

 

With FMX (I developp only one app, that you'll be able to see in a video soon), the art is really difficult for Embarcadero. I can undertsand that, of course. But I can also be worried when, obviously, the code has changed and it has not been tested.

 

Like I saw some years ago in a post about a developer : solve some bugs and add new ones. I recognize myself in this "joke". But from Embacadero, I'm a little bit worried.

[Guest]

55 minutes ago, weabow said:

But it would be a lie to say that it's perfect.

Who said that?

[David Schwartz 430]

6 hours ago, Dany Marmur said:

@David Schwartz, nice neat write-up!

 

Is that something you have in your back-pocket or did you just type from the top of your head?

 

Either-or, it became a very IMHO pertinent guide into Delphi's quirks.

Then, being first and formally an educator, there are all the quirks from other langs/environs that people brings into the D-word for no reason what so ever. I'd like to see a similar concise writeup about all those pitfalls 🙂

 

Thanks!

I just made a list of some stuff off the top of my head. These are all things I run into pretty regularly, so they're not very mysterious.

 

It would be instructive to make a list of all of the different ways the following three common idioms are expressed by different programmers in different projects, and how many variations can be found within the same large project:

* Logic that would use a Case with a string discriminant if the language supported it

* Ways of mapping Enums or regular consts (both numbers and strings) at run-time to some kind of display string that's more readable, including how they're initialized

* Form interactions (we could be talking 2-3 DOZEN here!). Variations would include these idioms for both getting and setting values in the form:

-- auto-create vs. on-the-fly creation and destruction

-- constructor injection -- requires overloading Create that hides default ctor

-- property injection

-- method injection

-- direct access of members (UGH!)

-- forms that manage Add / Edit in the same form vs. one for each

-- embedded selection popups on fields: read-only vs. ability to add something new (requires another form)

-- field validation (before vs. after exiting the form)

-- Hiding / Closing / Freeing the form

 

Actually, I bet a whole book could be written on "Form Interactions in Delphi". It's hard to argue there's a "right way" or even a "best way" to do it, but there certainly are a LOT of ways!

 

Edited April 6, 2021 by David Schwartz