[fpc-pascal] Working on a new way to educate people about pascal

[Anthony Youngman]

On 29/12/2022 05:15, Anthony Walter via fpc-pascal wrote:
> I think most people can quickly figure out that SQL is a programming 
> language that is used to manage data stored in relational databases. It 
> is a relatively easy language to learn and use, especially for people 
> with a basic understanding of programming concepts. It's a widely-used 
> language in the field of data management and is based on simple, 
> English-like commands. SQL uses a straightforward syntax that is easy to 
> understand and learn. Many people find it to be a user-friendly 
> language, and it is often used as an introduction to programming for 
> people who are new to the field. It shouldn't be confusing to anyone who 
> has been programming for decades.

Well, I understand it was originally called SEQL, E for English, but 
they dropped that because it wasn't English-like. While the access 
language for one variant of the MultiValue databases I use was called 
"English", precisely because it was very English-like.
> 
> The line of code you provided is a SELECT statement that retrieves all 
> rows (indicated by the * symbol) from a table called "Customers." The 
> statement also includes a WHERE clause, which specifies a condition that 
> must be met in order for the rows to be included in the results. In this 
> case, the condition is that the value in the "Country" column must be 
> equal to 'USA'. Therefore, this line of code would retrieve all rows 
> from the "Customers" table where the value in the "Country" column is 
> 'USA'. The results of this SELECT statement would include all of the 
> columns from the "Customers" table for each row that meets the specified 
> condition.

Not my line, but it rapidly gets worse from there. What if you want the 
country name ...

SELECT CUSTOMERS.*, COUNTRY_NAME FROM CUSTOMERS
JOIN COUNTRY_CODES ON CUSTOMERS.COUNTY_CODE = COUNTRY_CODES.COUNTRY_CODE
> 
> I agree, deciphering your statement ought to be quite clear to anyone 
> with even a passing curiosity, which is why I was unsure earlier how 
> anyone on this mailing list was confused by SQL.
> 
I'm a database guy with maybe 30 years experience, I'm new to SQL and oh 
my god is it an over-complicated monster ...

LIST CUSTOMERS CUSTOMER_NAME COUNTRY_CODE

and (for the user) it doesn't get any more complicated than that, they 
just need to know the name of the field they want. Everything is defined 
in the *table* (or rather, its equivalent) so the programmer only has 
one place to look, not a mix of tables and views, and you can actually 
hard-code the equivalent of a join into the table. SO much simpler, all 
round ... I like to describe multi-value as a hierarchical 
object-relational database.

Cheers,
Anthony Walter Youngman (aka Wol :-)