Programming languages and what’s next

My review of programming languages I learned in during my years in IT.

BASIC

On the TI99-4a.
Could do everything with it. Especially in combination with PEEK and POKE. Nice for building small games.
Impossible to maintain.
GOTO is unavoidable.

Assembler

In various variants.
Z80, 6802, PDP 11, System 390.
Fast, furious, unreadable, unmaintainable.

Algol 68

Liked this language. REF!
Have only seen it run on DEC 10. Mainly used in academic environments (in the Netherlands?)?

Pascal

Well. Structured. Pretty popular in the early 90s.
Again is this widely adopted?

COBOL

Old. Never programmed extensively in it – just for year 2000.
Totally Readable.
Funny (rediculous) numbering scheme.
Seems to be necessary to use GOTO in some cases which I do not believe.

Smalltalk

Beautiful language.
Should have become the de facto OO programming language but failed for unclear reasons.
Probably because it was way ahead of it’s time with it’s OO base.

Java

Totally nitty gritty programming language.
Productivity based on frameworks, which no one knows which to use.
Never understood why this language was so widely adopted – besides it’s openness and platform independency.
Should never have become the de facto OO programming language but did so because Sun made it open (good move).
Far too many framework needed. J(2)EE add more complexity than it resolves.
Always upgrade issues. (Proud programmer: We run Java! Fed up business person: Which Java?)

Rexx

Can do everything quickly.
But nothing structurally.
Ugly code. Readable but ugly.
Some very very strong concepts.

Php

Hodge-podgy language of programming and html.
Likely high programmer productivity if you maintain a stark discipline of programming standards. Stark danger of creating unmaintainable crap code mix of html and php.

Python

Nice structured language.
Difficult to set up and reuse.
Can be productive if nitty gritty setup issues can be overcome.

Ruby (on Rails or off-track)

Nice, probably the most elegant OO language. Too nitty gritty to my taste still. Like it though.
I would start with this language if I had to start today.

What is next?

Visual programming? Clicking building blocks together?

In programming we should maybe separate the construction of applications from the coding of functions (or objects, or whatever you call the lower level blocks of code.

Programming complex algorithms (efficiently) will probably always remain a craft for specialists.

Constructing applications from the pieces should be brought to a higher level.

The industry (well – the software selling industry) is looking at microservices but that gives operational issues and becomes too distributed. We need a way to build a house from software bricks and doors and windows and roof elements.

Probably we need more standards for that.

Some bold statements

AI systems “programming” themselves is nonsense (I have not seen a shred of evidence).
AI systems are stochastical systems.
Programming is imperical.

In summary, up to today you can not build software without getting into the nitty gritty very quickly.
It’s like building a house but having find your own tree and rocks first to cut wood and blicks from.
And then construct nails and screws.
A better approach to that would help.

What do you think is the programming language of the future? What need should it address.

In Layman’s Terms: (Visa) Format-Preserving Encryption

One of my clients asked me about Visa Format-Preserving Encryption. Could look into this. I am sharing a summary here.

FPE is …

Format-Preserving Encryption (FPE) is about encrypting so-called structured data, such as credit card or Social Security numbers.

With FPE you can encrypt data in such a way that does it not alter the data format.

Your data may be credit card numbers, account numbers, social insurance numbers, addresses, postal code, FPE will encrypt the data and the outcome will look like a credit card number, account number, social insurance number, address, postal code.

That’s it.

With this you can encrypt data per field without having to make big modifications to your existing application.

Then we come to the real goal.
We can have better data privacy and security. We can agree and adhere to certain industry standards for data privacy and security, such as PCI DSS in the Payment Card industry.

And the Visa?

Visa have invented and patented an algorithm to realize FPE and use this in their card handling. Called VISA Format-Preserving Encryption.visa format-preserving encryption

Why do we need this format preservation?

Sensitive data must be encrypted so that malicious people can not read that data. In financial transactions this is of course very important.

A problem is that with encryption the format of field could change. Traditional encryption algorithms take data as a byte stream, and turn it into another byte stream.

If you have a string of text, such as a name, after encryption this encrypted field may become larger than the original field, it may contain numbers or funny characters, or it may have become be a bigger field. Or if you have an account number, after encryption there may be characters in the result. Or there may be more digits in the result than in the account number.

This change of format of fields can cause several issues in applications.

Column sizes in databases may be too small to contain encryption results.
Fields in programs may become too small
Test data for application can become problematic.
It can become impossible to implement if these fields are used as keys in relational databases.
Your analytics may become problematic.

To prevent all these issues Format Preserving Encryption was invented. With it we can encrypt fields, but process these field in the programs as if they were not encrypted. The program is not aware of the encryption.

Clearly I am leaving out details. Fill me in where you feel necessary, I’s appreciate it.