I started learning Pascal (using Turbo Pascal 7) in ca 2003-2004, then learnt Delphi to write Windows desktop apps with MySQL. Probably pretty advanced for a high schoolers at that time.

Pascal is a general purpose programming language (like C/C++), which is not limited to teaching programming basics. The first Photoshop and classic MacOS were partly written in it.

All the cool kids nowadays most likely use Go or Rust. Pascal is still alive pretty well, even though you don't see it often enlisted on job vacancies these days. Now you can use Delphi to write MacOS, Android, and iOS apps as well. If you want to write desktop apps which easily buildable on Windows/Linux/Mac, then Lazarus is a good option. Of course there's an ongoing effort for Android: LAMW (https://github.com/jmpessoa/lazandroidmodulewizard)

A good reference is "Pascal in Three Days". Should be enough to help you learn the language basics.

Not sure if there are many now, it was always a commercial platform. Here's the gist based on what I remember. I wrote a bunch of Delphi apps in the 90s and actually my first open source project was called the Pythian Project which despite the name was an effort to create a 3D MMORPG in Delphi.

Delphi was a combination of a lightning fast compiler which produced small and memory-efficient binaries, a fairly advanced OOP language called Object Pascal, a widget toolkit that wrapped the win32 API, a (for the time) pretty advanced IDE with visual GUI designer, and a giant pile of frameworks for Windows-specific stuff like COM and database access. The primary designer of Delphi was eventually hired by Microsoft to C#. It cost a few hundred dollars in its heydey and that let you build and redistribute as many apps as you wanted for free, these days it costs thousands of dollars.

Delphi was a child of its time. In the 90s and early 2000s the primary environment programmers targeted for app development was Windows. The web existed, and people were trying hard to make apps with it, but they were extremely crude and slow so any self-respecting app developer was making desktop apps. And because GUI toolkits were very expensive to develop, there was really only one or two games in town for that, the main one being Win32. Only one tiny problem: Win32 API sucked hard. It was designed in the 80s for C programmers and wasn't particularly good even then. As a consequence a whole pile of products and languages sprang up that tried to give developers access to the large amount of functionality Microsoft offered, without having to actually use their API. The Delphi VCL (Visual Component Library) was such a tool and was a pretty good fit, being as it was characterized by manual memory management, tasteful OOP design and good C interop.

Delphi programs are split into files called "units". Each unit has two sections labelled the interface and the implementation. Types go into the interface, code in the implementation. It's a bit like how C uses header files except more rigorous and tightly enforced. Unlike C/C++ you can't (couldn't?) have circular dependencies between units, which forced a very hierarchical structure on programs.

The Delphi compiler was extremely fast, partly because it was a single pass compiler and partly because it didn't do much/any optimization. For desktop apps that spent most of their time blocking on events that didn't matter, whereas fast iteration speed did, and in this way Delphi carved out a loyal following of developers who didn't want to deal with Microsoft's slow C++ toolchain and poorly designed APIs, nor the designed-for-beginners Visual Basic product.

A big part of Delphi's appeal was the visual window designer. A quasi-marketplace of components existed and when you installed a new component, it would appear in the components tray that was always visible at the top of the screen. Components could be dropped onto UIs, have their properties be adjusted, be connected together, event handlers could be filled out by double clicking etc and they could be visual or non-visual. Also, you have to understand that at this time components are primarily distributed as binaries and sold by companies. Open source was little known in the Windows ecosystem, so there was no notion of dependency or package managers. To use a component you bought it and installed it. Microsoft had a standard for components called OCX and I can't remember what the Delphi equivalent was.

Many Delphi apps connected directly to a SQL database engine and issued queries as the logged in user, via something called the Borland Database Engine. I never used it so can't say much about this, but it's worth noting that this two-tier approach had a lot of advantages and there may be good reasons to bring it back! I'll be giving a talk on this idea at KotlinConf in April. For example SQL injection is impossible by design when your database knows who you are, because the DB engine is enforcing the right privilege level on you. It also means you don't have to think about REST, JSON, GraphQL and all the plumbing that web apps require because the app can just issue queries directly and bind the results straight into UI controls. This is one reason why Delphi programmers tend to feel their environment is highly productive.

It had quite a lot of downsides compared to modern development. After the designer went to MS the platform entered a period of decline. The language was good for its time but fell behind due to lack of investment, the product was fundamentally Windows only and an attempt to bring it to Linux (Kylix) was a resource-sucking disaster. Borland renamed themselves to Inprise which everyone hated, and spent lots of time and money on esoteric enterprise features like CORBA. Meanwhile, like Windows, they largely ignored the question of internet distribution meaning that they started to be left behind as the web took off (which elegantly solved the distribution problem, at the cost of regressing in virtually every other department). Borland tried to bring Delphi to web development but without the VCL and GUI stack it lost a lot of the justification for its existence, especially as Delphi's natural domain of business apps really benefited from garbage collection which Delphi didn't have.