Peter wrote:
. For knocking out PC apps, almost everybody is using M$ VC++
Almost nobody is using MS VC++ for desktop apps. C++ is popular for videogame programming (because it’s an OO language which keeps some of the lower level features of C, and most of the time you don’t want a garbage collector if you’re trying to get as close to a realtime system as possible, which videogames tend to be).
The top 3 languages currently are Python, straight C and Java. For desktop apps, generally Java and C# are preferred today. Straight C probably remains a top 3 language due to all the embedded work going on.
By the way, ECMAscript is JavaScript’s real name (how Netscape didn’t get sued by Sun for infringing the Java trademark, I don’t know – and JavaScript has nothing to do with Java).
> Java today is the job protection equivalent of the Cisco Certified Engineer qualification
Why do you say that? I use Java in my current day job (well, till I leave that one on the 19th and go to a C/asm job :-)) and it’s accessible, new grads we hire generally know it and can get to grips with the environment quickly and get productive with it. It’s been a top 3 language for years.
Peter wrote:
I wasn’t referring to the garbage collection delay.
What, then, was absolutely dangerous about GC in any safety critical application?
alioth wrote:
The top 3 languages currently are Python, straight C and Java. For desktop apps, generally Java and C# are preferred today. Straight C probably remains a top 3 language due to all the embedded work going on.
For a long time now, runtime performance is not the major issue in most application areas, programmer performance is. That’s why software design with many layers of abstraction is popular in spite of the runtime overhead it incurs.
It has been known for a long time that there are languages which gives a magnitude greater programmer performance than the usual Java, C# etc. group while giving at least the same or at worst marginally lower performance. These languages are considered “academic” and only occasionally used in industry. But when they are, it is usually with great success. E.g. Klarna uses Erlang for its performance and mission-critical backend systems.
My guess is that the reason such languages don’t see more industrial use is that, due to the great demand for software developers, many developers have marginal or zero training in computer science and find the learning threshold too high.
It is one of many differences between academia and reality 
One needs a new language like one needs a hole in the head. In the real world one needs to develop products that work and the language is chosen for how many can use it and how many can pick it up if the original author leaves. Performance of C is very close to assembler today; probably within 1.5 on average, but to get the 1.0 one would need to write hand-crafted assembler which takes longer, far fewer people can do it, and most code is not that performance critical. One can also make C faster with dodgy constructs…
In academia one can use “teaching languages” like, in my univ days, Pascal. That language was almost completely useless to anybody leaving univ. In science / engineering, Fortran was universal, but academics hated it because of the lack of structure, and the ability to get code running without thinking about it much in advance. I used to write my exercises in Fortran and then when working translated them into Pascal line by line 
But then univs were openly proud of ignoring what they called “manpower planning” (turning out people who were useful in the economy) so this was fine. The result was 3 years of one’s life largely wasted in terms of gaining useful skills. Most people who left univ and who were “useful” were ones who had a personal interest and ran a hobby e.g. building computers in their spare time, at the expense of socialising.
Businesses who adopted some unusual tech generally had problems. I know a guy who ran a company selling a product which could have been done with any CPU known in the day and in C, Basic, or whatever you got a compiler for. But his design guy did it with a Transputer (or a few) and coded it in Occam. The result was a total nightmare for years, eventually reduced to buying up Transputer chips from vintage collectors and museums. Eventually the whole lot got ripped out, at great cost.
Peter wrote:
In the real world one needs to develop products that work
You’d be surprised by the amount of collaboration between academia and companies that are successful in the real world. E.g. my colleague Tobias Wrigstad is a programming language design expert (something which, according to you, is as useful as “a hole in the head”) who has a long-standing collaboration with Spotify and works part-time for them – and believe me, that is not out of charity.
Or if we look at my own field of research, formal methods. Since the Pentium division bug debacle, the microprocessor industry is one of the major users of formal methods, which before that was widely regarded as an academic exercise without any relevance in the real world. Another good example is the software for the automatic Paris metro line 14 which opened in 1998. The safety-critical parts of the software was developed using formal methods and is still running version 1.0.
OK, this is shifting the goalposts around all over the place.
Formal methods are limited to trivial software functionality. And eventually the software needs to talk to hardware and what does one do about that? Start with a typical ARM32 with peripherals, with silicon errata a hundred pages long.
The safety critical parts on that train line were probably 1% of the # of lines of code.
Perhaps the drift of what I am saying is influenced by who is paying. If I am paying, I want a solid product which can be maintained for many years (industrial electronics; long product life) and I want it in a language which won’t become a fad which only a few 1k/day people can practice 10 years from now. This points firmly to C. Assembler is hardly ever needed especially with the drift to lots of peripherals like DMA controllers which if used cleverly really speed things up. I’ve just done a waveform generator project (basically a KI256 emulator, so two LVDTs) which runs almost totally in on-chip hardware with just a 4us ISR every 2ms. If somebody else is paying (a characteristic of academia in particular, and probably especially Sweden of all countries in Europe) then one can do all sorts of interesting stuff.
Arm assembler is very nice but C comes very close now, and ARM is pushing to have a maximum of C, even exception handling, with specific directives to as to be compiled with the right instruction. I have made a lot of these in ASM, but now low level C(armV8-M for cortexMxx) is really straight forward and efficient. Of course i’m not taling about very specific algorithm with hw acceleration. But again, if this is using hw accelerator that are not inside cortex, C with some intrinsics is as efficient and much clearer – which is all the job of low level programming.
Everything higher is garbage :D. C++ is messy and Go lang is for young idiots :P.
ARM32 is very good for C, with all exception handling done in hardware, so the ISR can be written totally in C like any other function, without special declarations like __interrupt. The way that was implemented is really cunning (pushing magic values on the stack, etc).
I use asm only for startup code, and mainly for clarity reasons.
My biggest complain over ARM asm is the fact that it follows ARM architecture develoment which is always moving with their lineup. It’s been the case now for 20 years, and actually accelerating.
This thread is cracking me up, mostly because of the number of us pilots who come from a software engineering (or EE with SE experience) background. My airplane partner is also an engineer, which makes me wonder what share of pilots we engineers comprise. In any case I usually try to stay out of programming language flame wars, especially when they’re largely semantic as this one is.
