I have a box from IBM with a version of PL/I that can run on Windows. I did run it years ago on Windows XP. I no longer run or want to run PL/I. I don't expect anyone to use it.

I bring up PL/I here on HN occasionally just as an example and lesson in programming language design. It's got some good features now lost, and for people interested in programming language design maybe some of the features could be brought back.

Since there has been a complaint on this thread that .Net style object instance de/serialization is slow and otherwise not so good, part of the problem is that such an object instance is not all by itself in some range of sequential memory addresses and, instead, can be scattered all over. So, de/serialization needs implementation by the language developers. So, HAVING the desired data in sequential memory could have an advantage, e.g., in speed, that is, just copy the contents of memory in the block of addresses -- tough to be faster than that (ah, do it in assembler and use some string copy instruction assuming that X86 has one of those!). Could do similar things for the simpler versions of C structs.

But in cautious shops, running code to get to memory addresses could be frowned on!

A broad point about PL/I is that its structures are nearly as useful as the .Net style classes but with much faster and simpler addressing. In programming language design, that's a little point to keep in mind.

I wrote enough C code to see how nearly all that syntax worked. So, maybe someday I'll write some C# code to be sure I know how its version of the C idiosyncratic syntax works!

Since I'm a sole, solo founder, floor sweeper to CEO, of my own startup, I get to concentrate on the tools my startup needs instead of tools someone else's startup uses!

The key-value store discussion here is good: I'm concluding that my needs are simple and my simple code is enough for those needs, that from the experience of others here in time I should want more functionality, and maybe should convert over to Redis. By then I might be hiring people to do such things.

I'm not sure that having my code in VB.NET is a serious dead end: As I understand, C# can do what VB.NET does with just a different flavor of syntactic sugar, there's a translator from Microsoft to go from VB.NET to C#, and the actual semantics are so close that for the corresponding language features (some of the more recent features in C# may be missing from VB) it is fine to call one of the languages from the other. That is, as I understand the situation, the real work is to get to the .Net Framenwork and the CLR (common language runtime) and VB, C#, F#, etc. are all essentially equivalent for that work. So, for differences we're talking some functionality and otherwise syntactic sugar.

My current work is more nonsense: Last night I started a run of Robocopy to do an incremental backup of one of my hard disk partitions. This morning Robocopy had completed without errors, but what it copied just as an incremental copy was about 80% of the whole disk partition when I've had only minor activity on that partition since the last full backup and turning off all the archive bits (archive bit OFF means that the file has been backup up since it was created or last changed and ON means that the file was created or changed since the last time the archive bit was set OFF).

So, somehow that disk partition got a LOT of archive bits turned on.

Open Object Rexx has a cute function can call to get a really nice description of everything in a file system subtree, one file/directory per line, with archive, hidden, system, read only bits, time-date stamp, size in bytes, full tree name.

So, I compared two of these files and found that after the last full backup I really did set all the archive bits off and for the incremental a lot of REALLY old files, going back years, still had their correct time-date stamps, had NOT changed, but DID have their archive bits set ON.

Bummer. Something has been walking around in that tree setting archive bits ON for NO good reason. Really big bummer.

So, to explain, the partition drive letter is K:. There are some files in the root of K:, but mostly the files are in K:\data01, ... K:\data05 and K:prog01, ..., K:\prog05. Right, separation of data and programs!

So, looking, all the archive bits set ON for no good reason were in just K:\data05. Hmm.

What could have happened?

Well, this computer is one I built from parts, running Windows 7 64 bit Professional SP1, but I also have an HP laptop running Windows 10 Home Edition with, of course, all the latest updates whether I wanted them or not.

And a week or so ago, I got okay with

net share

net use

etc. to set up file sharing between the two computers.

Well, I gave the Windows 10 system access to the Windows 7 directory, right, you guessed it,

K:\data05

That about has to be the cause. Somehow letting Windows 10 share the Windows 7 directory

K:\data05

had the Windows 10 system walking around all over that directory, including several directory levels deep, and to some files years old, and setting archive bits ON.

Bummer.

So, no more such sharing! I'll create a directory, say, HP_laptop_share, in the root of a partition and let Windows 10 share it. I'll just put temporary stuff there. And unless there are more bugs, Windows 10 will be limited to making a mess only in that directory

HP_laptop_share.

So, with the HP OFF the Windows 7 system, I'll do a full backup, set the archive bits off, and keep Windows 10 the heck OUT of there! Lost half a day with this. I call it mud wrestling. I has NOTHING to do specifically with my startup. ALL the work unique to my startup has been fast, fun, and easy for me -- the difficulty has been literally YEARS of mud wrestling, all for no good reason. What do others do about such mud wrestling?