Thursday, 13 April 2017

TIOBE Index update - top 4 languages are going down

The TIOBE index shows:

  1. Top 4 languages are going down (Java, C, C++, C#)
  2. Delphi is now significantly more than 50% the size of Microsoft C#
  3. JavaScript and Delphi are keeping their share
  4. R is going up, fast

It seems that there is a general move away from mainstream languages, towards other languages like JavaScript, R, PHP etc. R is probably rising because of the need for more data analytics, and large organizations have a tendency not to make paid statistical software available to employees that need it - and even universities that train doctors are now switching to R instead of STATA, SAS, SPSS etc.

For JavaScript, I heard a good recently, which it keeps being so popular: It is one of the few programming languages, that you can use without installing any software on e.g. your company computer.

Will Delphi overtake C# and Microsoft .net? Maybe - Delphi works on mobile phones, but Microsoft .net doesn't.

My personal opinion is, that you should pick the development framework that suits your needs, with regard to productivity, legal issues, tool-supplier support, longevity expectations, deployment options etc.

Friday, 2 September 2016

System architecture and QA in management

As IT becomes a bigger part of everyone's business, so does system architecture and QA. Whenever we see a big IT project that fails, the cause of the failure often comes from having management that does not pay enough attention to system architecture and QA.

I think all readers of this blog have seen managers, that take decisions based on a typical project management approach, where physical meetings and physical hardware gets more attention than the architecture of the software, or the management methods required to generate good quality software. The most recent I heard, was an IT project manager who said: We just need to make it as good as we can. However, the IT system was meant to produce vital calculations for the owner, so "as good as we can" is, in my opinion, an unacceptable attitude. Either you do it right, or you report back that you cannot be sure to do it right.

The idea of project management is actually quite simple: Always make sure to tell people who does what when, and make sure it happens. That is where QA comes in. Most IT projects are too complex to make a project manager understand the details. So, in order to help the project manager, you should have a fairly detailed QA system for your software development. This QA system should cover planning of detailed design, source code maintenance, system maintenance and how to deploy it. In addition, there are many things that are hard to verify, so you should have a documented programming culture that explains how the programmers make detailed decisions, and remember to make sure, that your programmers know it, and report if they see violations.

All this must be required by the top management of modern companies. Also, there is often a lack of review of whether the architecture matches the business model, the business direction and possible future business directions. A business may want to keep its business model options open, and sometimes options are closed by system architect decisions.

Even when system architects or other design engineers come into the management, these processes are often forgotten or not executed properly.

One of the reasons why this happens, is because humans were not created for making perfect products, or following Quality Management Systems. The mathematical perfection, that is sometimes required to get everything right, collides with other skills that are also required to create great looking products, useful products etc. And system architects are often not good CEOs. So, in the end, it usually ends up being dependent on respectful, open-minded cooperation of a management team that really knows their stuff. Not all companies have that.

Sunday, 8 March 2015

35 years old Arduino-like setup with Pascal

I do not care much about products or constructions from the past, that cannot be reproduced or used, but in this case, my brother's old construction from the late 1970s made me look again, because it looks so much like what people do with Arduino kits.

This is a computer programmed using Compas Pascal or Turbo Pascal:


  1. CPU: Zilog Z80, of model Z80CPU01. This is probably running 1-2MHz. The Z80 was an extended version of the 8080 CPU, on which the 8086/8088/Intel CPU line of CPUs was built.
  2. One EPROM for the runtime
  3. One EPROM for the actual program
  4. 5x4 keyboard on the back, suitable to be used as a 4x4 hex keyboard with some more keys.
  5. Some RAM chips etc.
  6. I/O pins for easy access.
Unlike today, where we can program Arduino boards etc. using flash, easily, that kind of technology was unavailable or extremely expensive. Therefore, EPROMS were used, which could easily be erased using an ultraviolet lamp, and easily re-programmed using this board, which used the Centronics port for I/O to the programmer's computer, as USB was not invented back then.

The main computer, that was used for programming, could be a Zilog Z80 Nascom computer, a CP/M-80 computer, or any homemade computer that was using a 8080 or Z80 CPU.

Compas Pascal and Turbo Pascal were obvious choices for this, as the compiler was fast and generated great code, and therefore boosted programmer productivity a lot.