To still add something to the discussion -> I never coded on a black&green CRT, but I did learn programming on an environment doing 24x80 16colour ... graphics? Text graphics. (this was ~1994)

It was fun. For the first few years of my computing experience I never really left DOS and kept trying to reproduce the shiny Windows stuff in there. I still think that was better and more fun than when I briefly tried learning how to make "real applications" before jumping ship to Web.

I was totally engrossed in writing custom batch files using ANSI.SYS escape sequences to create text "graphics."

While I think there's money to be made in maintaining those old systems, I would just go insane not keeping up with technology and using modern stacks. CS has progressed for a reason, the level of abstraction today is so much higher that we don't have to write from scratch all the time, there are well tried and tested components.

Setup=Windows PC && OS=Unix, doesn't seem to make much sense, unless you mean Windows as a terminal (putty et al.)

Now, back to Python...

Because I'm not doing the same thing over and over. I'm just using the same technology. I rarely encounter things I can't do with it. I love Pick more than anything else I've ever used.

but there's not way on earth I'd want to be still using BASIC, or Pick for that matter

Pick is almost like a cult and for good reason. It's incredibly elegant, simple, and powerful. Most Pick programmers, even after learning newer technologies, still love Pick and use it whenever practical.

but if you try new tech stacks you'd never want to go back to systems from 40+ years ago

Exactly the opposite of my experience. I've tried many tech stacks and have come to appreciate their pros and cons. But I love coming back to "old faithful". With Pick, I spend most of my time on the problem at hand, not the tech stack. Not so true for many more modern technologies.

I would just go insane not keeping up with technology and using modern stacks.

I never said I didn't keep up. I do and I love to. The thing that would make me go insane: not having fresh customers with fresh problems.

CS has progressed for a reason

Make no mistake about it; the biggest reason has been the internet. So much CRUD technology is so powerful and stable, there hasn't been as much need for "progress".

the level of abstraction today is so much higher that we don't have to write from scratch all the time

I never write from scratch. I use the same 30 or 40 building blocks for every project.

there are well tried and tested components

I'd say that Pick's 40 years and millions of apps make it well tried and tested, too.

unless you mean Windows as a terminal (putty et al.)

I do. Putty on my left, Firefox on my right.

Now, back to Python...

Oy.

Probably a lot more than you think.

I've seen estimates of 1-2 million COBOL developers worldwide.

Rocket and IBM have done a bit with U2 to open up the multi-value data files and UniBASIC programs to "open systems", i.e., Java, .NET, SOAP, REST-ish, etc.

It's still a bit of a pain because values are strings, one has to extract MV/SV data by tokenizing along delimiters, there's a massive amount of data duplication (no FK relationships), multi-byte causes problems with older programs (and many, many of them are very old programs), and there's no concept of data queues as you might be expecting if you've worked in an OS/400|i Series|System i|i|etc. shop with RPG.

That said, it runs happily on Linux and is quite robust.

Many of the problems relate to programming practice. As you can imagine, there are some "lifers" who don't stretch themselves, argue GOTO vs. GOSUB, copy-and-modify existing programs for new requirements, and don't use source control or automated unit testing. Then there are those who refactor 17 copied versions of programs doing basically the same thing into a modular package and slap an object-ish API on top.

With a rational approach, the environment is actually quite pleasant, but it does take some discipline. It is difficult to retrofit a more rigorous engineering process onto legacy code, but that's the case whether it's Pick/UniData or any other programming environment.

  - level of normalization determined by programmer, not DBA
  - relationships (joins, etc.) enforced at program level, not schema
  - no typing (everything is a string)
  - DBMS performance is mathematically predictable & determined (hashing)
  - everything is variable length
  - anything can be multi-valued or multi-subvalued
  - No schema needed. Just code.

like an engineer re-inventing the process to build bricks anytime a new building is requested.

industry observation, not personal.

shouldn't there be a work order processing standard solution for aerospace by now?

I'm sure there is. Just like there are blog, website, & CMS standard solutions. And plenty of people using them. I never see them because those people would never call me. Like many other programmers here, I imagine, we only see the customers who need something custom, almost always for good reason.

I wouldn't choose PICK for a brand new project today, but as Ed says, there's life in the old dog yet...

asking cause 28 years is an eternity in regards of IT - or at least that's what we hear day in, day out.

There are probably several, all mutually incompatible in some way, and chances are every company picks bits from each to make their own "local" standard (a local standard that gets worked every time the name associated with a C*O title changes).

Sometimes we are not in a position to control the constant wheel evolution and just have to get on with it & accept the paycheck.

I commonly have to code in older versions of my preferred language, and it's always a bit grating. I'm always pining for the newer features that I've grown accustomed to.

I don't miss that language one bit.

Now PICK as a data storage. Not bad, but did nothing well either. Could be I have the reverse of positive nostalgia on this one.

Small world.