With the passing of ledgens, what advice would you give to teach a new generation?

[Optimus01010101]

With the passing of Jon Sisk, and all of the responses that I have seen here, it makes me wonder about the next generation.

Pick, and it's different variations, are still all over the world, still being used. But, the model is now alien, and don't get me started on the obvious problem with the name of the programming language.

I have a system of training with new hires. It is a hit or miss at time, and I have to adjust after each time. But one thing is now a constant.

Every new hire has to be treated as if they are being introduced to an alien world, because the facts are that they are going into an alien world.

So, what do all of you do in those instances?

[frosty]

I'm teaching a "Pick" training class this week and next, so I've got a current perspective on this. Only one trainee in the class, a young man with a computer science degree, and some experience with modern languages (Python, TypeScript) and SQL databases. The kind that give you a blank stare when you try to explain a Pick-like environment. I've got a couple basic themes that I've repeated for five days and will repeat for another five days: (1) Everything is an Item in a File (2) Every Attribute of every Item is a string (3) It's not a database; it's a data store (4) If you're rigid in your structure of the shape of the data in each attribute, you can treat an Item in a File as if it were, in truth, a row in a database.

If they can wrap their heads around that and show up for class the next day... that's a good sign.

[Wol]

On 24/08/2024 03:46, frosty wrote:
> I'm teaching a "Pick" training class this week and next, so I've got a
> current perspective on this. Only one trainee in the class, a young man
> with a computer science degree, and some experience with modern
> languages (Python, TypeScript) and SQL databases. The kind that give you
> a blank stare when you try to explain a Pick-like environment. I've got
> a couple basic themes that I've repeated for five days and will repeat
> for another five days: (1) Everything is an Item in a File (2) Every
> Attribute of every Item is a string (3) It's not a database; it's a data
> store (4) If you're rigid in your structure of the shape of the data in
> each attribute, you can treat an Item in a File as if it were, in truth,
> a row in a database.

Thanks to the name of the ScarletDME, I'd change (3) to say it's a Data
Management Environment - I think that's a very good description.

(2) It's not "Every attribute of every item", it's "Everything" is a string.

And (4) It's a DEscriptive database not a PREscriptive database.
Everything in a File should be in 4th Normal Form. You don't normalise
your data to create your tables then denormalise to try and regain what
you've just lost. What you do is an EAR analysis.

Entity - what real-life objects are you storing - these are your tables.

Attributes - what are the attributes of those objects. (This includes
relationships - the foreign keys of related objects are attributes of
this object.) And do you have any "foreign" attributes - this indicates
you've got your entity analysis wrong. Don't forget you can store
multiple values of an attribute in a single row.

Relationships - foreign keys that link to other rows in other tables.

(Knowing how to do a relational analysis is great. Failing to realise
that academic theory is usually fails miserably in the real world is awful.)


You said this guy had a Computer Science degree and "some experience
with SQL databases". That's like claiming your history degree gives you
an understanding of British History simply because you studied the
Tudors! Talk about Google Big Query - how it's re-inventing the
MultiValue data structure. Talk about Amazon DynamoDB - a schema-less
3rd-gen NoSQL database that uses key-value like the underlying Pick
datastore. Basically, in a polite way, tell him if all he knows is SQL
then his degree was seriously lacking in any real-world content
(actually, isn't that true of most degrees?).


And a biggy - Pick is BLINDING FAST. I had this discussion recently on
LWN - the academicians are obsessed with "constant response time" - they
want guaranteed O(log-n) response so they can guarantee the database
will respond. In order to do this, the cost of making the slow queries
faster is to slow everything down - EVERYTHING takes O(log-n) time. Pick
accepts that some queries will be slower than others, but that makes the
majority of queries O(1) - "instant response".

SQL/Relational says "don't worry about optimising your data, we'll do
that for you". Pick says "you're a database analyst - ANALYSE!!!". Pick
pushes far more work onto the analyst programmer up front, but the
result is a database that's a joy for the user, not one like I have at
work where operations typically take 15 minutes or more, and in the
morning pretty much everything falls over with "database timeout" errors!

Cheers,
Wol

[geneb]

On Fri, 23 Aug 2024, frosty wrote:

> I'm teaching a "Pick" training class this week and next, so I've got a
> current perspective on this. Only one trainee in the class, a young man
> with a computer science degree, and some experience with modern languages
> (Python, TypeScript) and SQL databases. The kind that give you a blank
> stare when you try to explain a Pick-like environment. I've got a couple
> basic themes that I've repeated for five days and will repeat for another
> five days: (1) Everything is an Item in a File (2) Every Attribute of every
> Item is a string (3) It's not a database; it's a data store (4) If you're
> rigid in your structure of the shape of the data in each attribute, you can
> treat an Item in a File as if it were, in truth, a row in a database.
>

I've always explained to folks that SQL stores data in two dimensions, and
Pick stores it in three. I try to describe how the system works in terms
of common, non-database terms. It helps.

g.



--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!

[Nivethan T]

I like the zumasys youtube videos as an intro:

https://www.youtube.com/@MultiValue1

My own thoughts:

I haven't actually tested this on a person so everything I say should be taken with a heaping of salt.

There are two parts to Pick and only one is truly alien today, while the other is just bad defaults. Pick the database is a truly alien thing and is a mindbend for people that only know SQL. Pick the environment, aka TCL, the query language and BASIC are only alien because the tooling around them by default is difficult.

I think one way of getting people used to Pick, the environment, would be to give them tools similar to what they already use. TCL is scary because it doesn't work like bash. Editing records in ED is scary because its not vscode.

I'll shill my shell, NSH  but there is a couple out there that make TCL so much better to use.

EVA is a vim like editor that works for both basic programs and multivalue data.

More importantly as I think everyone should be able to create a dummy database with a good dictionary:

NEW-FILE is a shorthand for CREATE.FILE that doesn't need any parameters. CREATE.FILE under ScarletDME is actually great for this as it just works.

ADD-DICT is a CLI tool to create dictionaries using flags.

ADD-DICT --FILENAME SOME-FILE --ATTRIBUTE 1 --NAME FROM --SHORTHAND -F

And to blow things away and start again:

DELETE-FILE DATA SOME-FILE

DELETE-FILE SOME-FILE

https://github.com/Krowemoh/TCL-Utilities

[Optimus01010101]

First, thank you all for your perspectives. I find, even as most of the computer industry and news is focus on the new "it" thing, PICK still hangs on, thus my question.

Most of what has been said I do use, however, there are some insights I may work into my next session.

Most of all, I would still love to hear from others on this forum as well. Just tips, nothing fancy. I think we all benefit from each of us sharing what our experiences are.

For me, I do agree that working with someone strictly from an SQL background is harder than one who has had little interaction with any database environment, think of those who use web technologies like JavaScript and JSON.

Those individuals seem to not be burdened with the dogmatic mindset of those from a background of SQL, and thus understand PICK far faster. For those from SQL, I do end up working with the "a file and items equals a table", but then add in that fields can also be a table, to try to show them the multivalue aspect of PICK. That approach I've had mixed results.

[Wol]

On 25/08/2024 14:06, Optimus01010101 wrote:
> For those from SQL, I do end up working with the "a file and items
> equals a table", but then add in that fields can also be a table, to try
> to show them the multivalue aspect of PICK. That approach I've had mixed
> results.

You'd probably get better results by saying that a FILE equals a view
over several related tables. And that if properly designed, a file is a
view over an object, as in OOP.

If they then ask what OOP is, you can ask them whether their CS degree
came from Disney :-)

Cheers,
Wol

[Tony Gravagno]

These days it's easier to explain the MV model to SQL people than before. They now have JSON and Vector data types as well as Spacial data types for geolocation - all of which store multiple values in a single field. "Multi-Valued Fields" are now a part of their lexicon.

"Database" is less of a mystery word - Sqlite underpins many device apps. MySQL/MariaDB and Postgres are globally recognized by non-techies because it's used in so many websites, and "some" knowledge of datbases, tables, and queries is a requirement.

Databases are also no longer limited to RDBMS and ... nothing else. The concept of a database is much more in the tech consciousness, less so as voodoo of the church of Codd, and more as simply a place to put stuff. This includes all of the NoSQL varieties and others, like Hadoop, Mongo, Redis, and JSON databases.

 

If you're talking with someone who doesn't know what a formal DBMS is, most people have some experience with Excel, Google Sheets, or LibreOffice now, and they understand the concept of multi-line text in a single cell.

So if you're teaching MV, it's easier to relate it to something that people know.

When doing trade shows, I only had about 10 minutes to get someone at the booth from zero knowledge to "oh I get it":

1. Create an account: This is your database.

2. Create a file: This is a table

3. Create items with atb 1 and 2 as Name and Age : These are fields in a record ... you don't need schema.

4. Create dict items: This is schema but it defines views, not constraints.

5. Create a BP file: Your stored procedures go here.

6. Create a fast and simple BASIC program that opens the file, reads and writes an item.

That's all you can get in a respectful 10 minutes of vistor time without overload.

These days there is so much more that relates to the modern developer:

- PHP, BASH, and NodeJS developers are completely familiar with server side code with no GUI, where in the past we were struggling with a more rigid client/server paradigm.

- The modern paradigm for communications from client (web app) to server is to use web services, aka sockets, and not direct database access with a library and ConnectionString. Since this is the way we've always done Pick connectivity, it's no longer an unusual way to do things (with tools like Linkar, MVConnect, mv.NET, QMClient, etc.).

- The world is now shifting (back) toward a better balance between client-side apps and server-side rendering, which used to be a hard sell when that was the only way we could do it with tools like Coyote and FlashConnect. (Yeah, I know, that's not entirely true about those tools, but it's the way almost everyone used them.)

- Because of those factors, it's easy to explain that MV can operate as a server platform, as well as integrating with any client technology, including devices, SaaS like Zapier, AI functions, frameworks like React and Angular, and anything else that they are already familiar with.

So, while this should be a golden age for Pick, as usual, those who are responsible for Marketing are completely clueless and still trying to figure out how to get more people to use the platform. SMH

Best to all,

T