Tech-inzichten door Niek de Greef. Reflecties op technologie, software development en de impact van digitale innovaties op cultuur en maatschappij.

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.

The Internet of Everything – toilet seats to human bodies

I walked into the restrooms. A mechanic stood at the sink fixing something. It saw him holding a toilet seat. He was fooling around with the wiring of the apparatus. Then he replaced some electronics components and rewired the seat.

Toilet sensors

It never occurred to me that even toilets could be usefully equipped with electronic features.

I asked the mechanic about this. He explained that the toilets in the building are all connected to the Internet. If there is something wrong with the anti-sceptic fluid produced by the toilet, it starts calling out for help. He told me that the towel dispenser was also connected to the Internet, so that when it runs out, a maintenance operator is called in. Makes sense.

Never has technology so much helped improve the First Little BIG Thing – – The Loo.

Towards cell sensors

So all things will be supplied with sensors. And it looks like the sensorized things are getting smaller and smaller. Reaching the nano space, see http://www.scientificamerican.com/article/the-internet-of-things-goes-nano/.

Sensors are reaching the nanoscale where they can flow through our blood and mend our bodies. Maybe fix cancer cells. Or detect issues with blood vessels. Or measure the chemistry in our bodies. They can be injected in plant to protect them from diseases similarly. Or in constructions to measure stability at smaller scales than we had ever assumed possible. Possibilities beyond imagination.

Neb sensors surveying the body

Imagine what it would mean if we could instrument every cell we like to. I would like a surveillance team of bot swimming through my body, like the Nebuchadnezzar in the Matrix flows through the sewers and tunnels of the abandoned cities.

To signal when my internals run out of supplies.

The problem with software

Software does not wear and tear. It does not break. It does not fade, evaporate or oxidate. Software is not affected by its environment. To update software to its changing environment code needs to be changed, by humans.

Another challenge is we can not proof that the software is programmed correctly. Testing helps, but: program testing can be used to show the presence of bugs, but never to show their absence (Dijkstra, EWD 249).

Software has become complex beyond comprehension. It resembles a dynamic system. Small changes in input can give major changes in output. Code is built on code and turns from structured material into amorphous mass. And we constantly change the input as well as the code.

So we must move to a different model for creating and maintaining software.
What we do today is gather requirements. From the requirements we build the software.
Then we test the software by translating the requirements into test cases (ideally – linking requirements to test cases is not such a generally adopted practice even).

Why not turn requirements in code, automatically? Instead of teaching programmers to create code, we should teach them to generate code. Then we can change the requirements, and regenerate the code. Or it can change/regenerate itself.

A recent article in The Atlantic discusses a coming software crisis. The remediation that is described in this article is to apply formal methods. This basically means we do not code but create a formal, mathematical model of the problem space. This model can then be turned into code. This code can be proven to be correct. The article explains how the existing formal methods, like TLA+, are still immature and there is still a lot of skepticism in the market on its applicability.

Formal methods have been around for a long time, but they never developed beyond an academic context. Translating more complex problems into formal models has proven to be very difficult.

For now, we will have to do with the current discipline. Which could do with more discipline.
Programmers often (must) start coding before understanding the problem, and having a comprehensive idea about the solution. They are caught up in the detail of programming. And modern languages (Java or JavaScript) do not make that easier. These nitty-gritty programming languages leave a lot of detail to be handled by the programmer – making it even more difficult to oversee a program’s complexity.

Also, a higher level of reuse should be encouraged. Every day in software you see programmers solving problems that have been solved for decades. Time pressures, and inaccessibility of existing code make programmers build yet another sort routine, search algorithm or data access mechanism. The building libraries of abstract, generalized libraries should become a common discipline among development teams.

Adopting a microservices approach (not necessarily the technology) will further help separating functionality, making the software system more flexible and therefore change-able.

I am a big proponent of coding for longevity but that is a very controversial opinion these days. But delivery speed is more important than delivery quality. Because things change so fast. Yes, this is true, but we oftentimes can not tell which code will last for decades and which code is quickly obsolete. So we’d better increase the quality of what’s delivered. And invest in methods and technologies that can help improve quality.

Google’s Documentation Style Guide – helping the writer in the developer

Google have published a style guide for their developers.

It’s a nice guide for all writers of non-fiction.

Some cute things:

On semicolons (I never know when to use) not much help (https://developers.google.com/style/semicolons)

Where to use semicolons is often a matter of judgment. Use them judiciously.

In the resources section the style guide refers to Apple’s and Microsoft’s style guides. (https://developers.google.com/style/resources)

Other companies’ style guides, such as the Apple Style Guide or the Microsoft Manual of Style.

Anthropomorphisms, which I like especially in documentation (makes them read like a novel, if done well), however not recommended by Google (https://developers.google.com/style/anthropomorphism):

Examples

Not recommended: A Delimiter object tells the splitter where a string should be broken.

Recommended: A Delimiter object specifies where to split a string.

Just one I did not understand (https://developers.google.com/style/headings):

Things to avoid in headings

Don’t use the following in headings:

Enjoyable.

Should you learn how to code?

Everyone in IT should know the basics of programming. (Also you should have installed some Linux distribution on your laptop. Even if its your laptop, it increases your understanding of the complexities of managing a platform.)

Program something

Program a crappy little program, you will understand more about the challenges of the programmer.

Derek Sivers wrote a nice article about why you should learn programming. https://sivers.org/prog
For him learning to code means self reliance and basic understanding are the main reasons.

Also experience the joy of building you own computer. I helped my son when he built his gaming computer. I learned at least as much as he did.

What language to start with

Derek recommends to start with HTML and CSS. Well, yes, agree of if you are interested in programming web sites. But HTML is such an ugly programming language. It’s like staring programming with BASIC. Before you know you think GOTO is a great flexible feature. While it actually is kitsch. I would rather start with Python, php or Java.

Build something useful in a very short time. Make it ugly. It doesn’t matter. Improve it step by step. Or start something new.

I like exploring programming languages.

 

I recently played with php. Built a small website showing photo’s from google images using random keywords.
Using MAMP.

Then played with python, programming an interface between Kindle and Evernote. Used Pydev.

Did some Javascript and node-RED.

A lot of Rexx programming. 

And Erlang.  That’s a hard one if you are not familiar with functional programming languages.

I learned a ton. I am always amazed what you can learn FOR FREE on the Internet.