Python is essentially today’s BASIC, but with significant whitespace.
Edsger Dijkstra said of BASIC “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: As potential programmers they are mentally mutilated beyond hope of regeneration.”
Hopefully the same is not true of Python!
Kotlin is now the “preferred language” for Android development so I’m not sure it’s that obscure these days (unfortunately for Java programmers, Android significantly lags behind on Java support these days – I think it’s still largely Java 7 and a lot has happened since then). Unfortunately nearly all of the Kotlin developers are Russian – who knows how much control the Russian state might have over them if they want to backdoor the Android ecosystem.
Just a dumb way of handling errors…
Couldn’t put it better myself! It would have been just as disastrous in Haskell or PDP-8 assembler.
Python is a truly awful language for anything longer than one screenful. That said, I am 100% sure it will still be around in 10 or 20 or even 30 years. It has been going strong and getting stronger for 20 years now. Its big advantages are that it is really easy to code in, and there are libraries available for just about anything you want to do.
The problem is that once your program gets bigger than a screenful or two, the absence of any compile-time type checking makes it just about impossible to make significant changes, and practically certain that there will be obscure corner cases where function x() expects an int but someone passes it a string, or whatever.
Personally I like Kotlin, which is kind of Python-esque but with rigorous compile time type checking. However it is just as obscure as Haskell or Scala, and the build system truly sucks. I wouldn’t dare use it for anything “professional” because of the impossibility of finding anyone to maintain the code.
It’s really hard to beat C for embedded/systems level development. On the projects I’m working on (large one on an ARM SoC quite a lot of memory, small one on RISC-V with 128k of RAM) the amount of control you’ve got over things like memory layout, especially when you get into linker scripts – and how you can see how things in the source code end up in memory, is really hard to beat.
However, don’t knock Java for big systems – Java is actually very quick these days, with good JITs, and on server-class hardware there’s often little CPU usage benefit from using C for the application side especially when you consider the benefits the language brings. The Java ecosystem (which is probably mostly off-limits to the developers at NATS!) is also very good and is probably the reason why Java remains a lot more popular than C# despite everyone hating Oracle more than they hate Microsoft. The JVM also has more than just Java now.
Python is in vogue today for embedded systems too. I looked at implementing it on a product I am developing now (a customer programmable (in C) protocol converter with some analog features) but decided it will be out of fashion in 10 years’ time. It would have also eaten all remaining RAM; about 50k 
Don’t even ask about the execution time overhead.
Osmo looks fun I had never heard of it.
The NATS stuff is mostly in Java but they can throw enough CPU power at it to work OK.
AFAICT it is nothing to do with any language. It might have been done in Visual Basic Just a dumb way of handling errors…
Thing is upper management might end up telling them to use Python/Java/Osmo1 because everyone else and their dog are.
The languages are niche, but so is the subject matter where they are most applicable. Which often means paying more for a good developer is possible, and cost effective, but see above about management.
That said, our endeavour to provide outsourced teams of developers writing code in functiona languages where it made sense failed, while people still keep on paying us money for stuff done in ‘language of the day’ by the same guys for the same amount of money without batting an eye.
They just have to get a job at Ericsson, but that’s no problem, with 104k employees
Weird languages are loved by CS teachers (it was Pascal in my time) but tend to be unusable in the real world.
This, after all, was just a stupid design decision.
Peter wrote:
All that does is selects for clever programmers who can get their head around these weird languages. And they are scarce, so very expensive, and cannot be fired. Those people could write as reliable stuff in C, or (much more slowly) in assembler. Or Fortran I’ve seen so many of these claims. Used to know an old guy who kept saying how Forth is great for safety critical systems… Well, almost nobody could understand it, so those who could were super clever and produced good code
It is all about what you’re used to. We start teaching functional languages (like Haskell, Erlang…) and students do just fine.
The main issues I have seen in server-level IT have been with logfiles overflowing the server space because the cron job intended to compress them and eventually delete them stopped working 
Usually this happens a year after the person who wrote the code left the company…
All that does is selects for clever programmers who can get their head around these weird languages.
Couldn’t agree more. All our code (the stuff that matters) is in C++. If you have the right mindset you can write extremely reliable code in C++, thank you very much. With the great advantage that you can fairly easily hire people to work on it. Write your code in Haskell or Erlang and… best of luck with that.
I agree, except this is not really real time. There is no microsecond or even milisecond precision involved.
Depends what you mean by real-time, I agree. What I really meant is that it has to keep on working, no matter what, because bad things will happen if it doesn’t. Imagine if the fly-by-wire avionics says “oh, this shouldn’t be a null pointer, I’d better write a log message and stop”. (Oh wait, it probably does).
What strikes me is not the “computer science” commentary but the name Frequentis AG.
They wrote the EAD AIP and approach plate database system. Many years ago I was involved in a project which produced a PC executable which grabbed a copy of that whole database (about 20GB then) and made a local searchable copy. The value at the time to pilots was obvious but it was never launched because of likely legal problems
But it was easy to write. It was immediately found that the login was totally fake. There was a complicated sequence of cookies and whatnot, designed to p1ss off anyone trying to do it with a machine instead of a human, but once you got a URL to something inside, that would work for days or weeks. There was no security whatsoever. And there still isn’t to this day. The system just tries to frustrate URL passing by inserting a token into the URL and trashing that token all every week or two (which is why EAD links posted here are useless; you need to download the PDF and drop it into your post). Only a complete amateur would have written that sort of code. No idea what they were trying to achieve. Maybe maximise the billable value by satisfying some “security dickhead” at NATS, maybe trying to avoid bots downloading the State secrets in there (the hidden google recaptcha with a threshold of about 0.6 does that very well), maybe something else. Maybe make it harder for bots to discover some crappy code in there which might make their customer demand a refund (although I doubt NATS would spot a crap product even if it bit them in the bum; the organisation is so top-heavy that nobody has any degree of freedom). They had some other anti bot code so when downloading the plates we had to put in random-ish delays to make it look like somebody was keyboarding it. But why block bots? You fundamentally cannot. EuroGA gets probably 100k bot hits per day and still this is about 1% of the server bandwidth (the cost of hosting is mostly the GB disk space but NATS etc run their own servers anyway so all this is “free”). We block Russia and China to reduce the malicious stuff a bit. No point in implementing a login at all. Just let everybody go in and download stuff, and use firewall rules to block blatent abuse like downloading the LKPR AIP every 100 microseconds.
Financial software tends to be less critical in that you can pull the plug out, and the people I have known who work there are pretty smart. The sort of people doing ATC software are mostly on LinkedIn and telling everybody they can’t get a job anywhere else
The whole thing was written in Java by a load of obvious hackers.
“Everyone knows” that you should use ASSERT statements to check for broken assumptions in the code. But that is a TERRIBLE idea in real time code. Much better to let one packet (or flight plan) be broken, than to bring down the whole system.
I agree, except this is not really real time. There is no microsecond or even milisecond precision involved. They have enough time to write debugs to a logfile and indeed they seem to have been doing that, which is how it was eventually sussed.
Or you use a language designed for high-availability real time applications such as Erlang. (Used e.g. in Telecom systems and systems like the WhatsApp server.)
All that does is selects for clever programmers who can get their head around these weird languages. And they are scarce, so very expensive, and cannot be fired. Those people could write as reliable stuff in C, or (much more slowly) in assembler. Or Fortran I’ve seen so many of these claims. Used to know an old guy who kept saying how Forth is great for safety critical systems… Well, almost nobody could understand it, so those who could were super clever and produced good code
The key thing is that each niche in programming has its own employment ecosystem. In embedded / realtime you have mostly C. In ATC and some other areas you have Java. In telecoms you have XYZ… Each one says their language is super safe and super brilliant. But in reality any program longer than about 100 lines (variable, obviously) cannot be properly tested…
Software will always have bugs. The bug here was bringing down the system, instead of isolating that FP and sending it to some human to fix. According to another plausible commentary I read, NATS already have a system looking for FPs which they know will break their software, and this French one is just another one to add to that list. Then the issue can be dealt with separately. Or not, if it happens once every 5 years.
