This is series of interviews with software developers interested in Ada programming language. The goal is to promote the community members and the language itself. Do you want to take part in this? Contact me!
The previous interview, with Vinzent Höfler, can be found here.
Today we will talk with Olivier Henley. You can follow him on Twitter and Github. You can check out his awesome-ada repository: a curated list of awesome resources related to the Ada and SPARK programming language.
I first graduated in Fine Arts but from as long as I can remember I always been attracted by the deep and beautiful implications of rational thinking. In my twenties I started to be interested in creating sculptures using machines. For a while I tried to learn the engineering needed to make robots as an autodidact but then quickly realised I needed proper training to get anywhere serious. I entered engineering school, electrical, and from there felt in love with programming. The depth of the discipline is incredible, you never stop learning fundamental stuff. I feel it always pushes me to better understand the world that surrounds us. To me it is one of the greatest mental exercise one can find.
Before attending engineering school, around 2004, I was working as an alpine ski instructor and learning C by myself using the Beej's Guide to C Programming. One evening I give a class accompanied by an older, part-time, instructor that designed chips for a UK space company for a living. All proud I tell him about my part-time C autodidact learning. Upfront he said: "Don't learn C, learn Ada?". Back home that night, curious, I got informed about Ada on the web but did not found much at the time. I understood the ‘deal’ with Ada but I also felt it was beyond my competencies to really argue a perspective about it against any other programming languages let alone C.
In engineering school, they taught us C++. I first did an internship followed by a full fledge job at Ubisoft Montreal. I developed a patent around the Kinect camera for the game Your Shape: Fitness Evolved; a 3D temporal filter implemented over graphic shaders. Then moved to some R&D, then AAA game productions such as Rainbow Six: Siege, followed by ForHonor. At Ubisoft, everything is C++/C#. These days I work as a software contractor for Autodesk, again full C++.
In my spare time, I work on two distinct personal projects; the details being secrets for the moment. I work with Ada, Golang and Dart.
During the years, the more I learned about software engineering, architectural strategies, optimization etc the more I kept coming back to Ada; in part to see what was their take on these issues but also because other languages always left me frustrated around some quirks elevated to defacto idioms.
Every single time I looked into Ada, I concluded they nailed the right solution. In my view the Ada design team always address core issues and do not give much importance to the 'sugar'. In the end that's what you want. By constantly addressing the fundamentals correctly, the language becomes 'freakingly' coherent and in turn, powerful. If you think about it, this worths gold. When you learn something in Ada you will almost never get bit by a side effect or an exception to the rule and everything is set in place to achieve correct program without impeding on performances. If you think C++ can be elegant and performant, you have never seen Ada code.
Few engineers from other languages are accustomed to such reality so they often fail to even understand the case for Ada. For them, software crafting is inherently a moving target and they accept all kind of ‘irregular frame of work’ as long as they feel empowered by some tools, syntactic/semantic shortcuts and a perception of novelty; an overall impression that a proper combination of these necessarily leads to a productivity speedup. What most do not realize is that any fundamental flaw or missing fundamental feature in a language will cost you and others tenfold what you might gain from the sum of any programming conveniences.
As an example, why would you even spend time using Python knowing that you’ll eventually hit the Global Interpreter Lock (GIL) and generally poor performances all along? Absolutely no programming sugar will ever compensate the fundamental limitations you locked you in over the long run. It is foolish to think that any ‘serious’ software does not need to be fast and will not eventually need some proper concurrency. In my opinion, all efforts to circumvent these flaws, eg. C core routines glued using Python, shows a tremendous lack of competency, curiosity, and knowledge. This kind of ‘architecture’ has systematically lead to pure extensibility and maintenance hell yet we are still flooded with ads and blog post suggesting to learn and use Python for everything. Since the 80s competent engineers have argued for an objectively better technology, named Ada, and most have ignored them, for dubious reasons, leading us to the mess we are in today.
Other good examples are cURL and OpenSSL. Have you ever wonder how many bugs, problems, headaches, security breaches and man hours would have been saved if those programs were written in Ada from the start? It is not even funny; yet you will find armies of pals ‘a la’ Linus Torvald or Eric S. Raymond, a majority being clueless about how and why Ada would have saved the show for decades now, to defend the C choice.
Ada shines because it is a pioneering low level and mature programming language that, when evaluated over all aspects of programming is still, to this day, the most modern, powerful, productive and advanced language there is. If you disagree or think that I am wrong, it is either because you do not know Ada or because you are not approaching the problem objectively. Ada has no garbage collector, has pointers, is bare metal and therefore exhibit tremendous performance on any platforms, is truly portable, has arguably the most advanced type system, has generics, is build around concurrency, has predictable timing capabilities, has mature tooling, has tons of provision to make huge code bases with complex requirements fly, is easy to learn, write, use, share and deploy. No other languages can claim to offer all that, period.
The typical work flow in Ada generally goes like this. You write the program and work out your solution to make it compile under the Ada ‘boundaries’ (the Ada compiler can be severe for newcomers that tries to code using a C based approach). When it compiles, you already secured a lot; depending on the complexity, often the whole thing is just virtually bug free at this point, hardened already. Then you run, test the program. Now if this soft has to fail it will fail fast; again you are securing great things right away. Ada pushes your program flaws to the surface in such a precise way, eg. compared to C++, it is almost a pleasure to find out about them; messages are concise, meaningful and strict in regard to the ‘coding contract you developed with the language when you first learned it’. The language mechanism and standard libraries exhibits excellency both conceptually and practically which really helps underlining design flaws. Once you revisit and fix the offending parts of your programs, which were in essence always flimsy or plain and simple not properly designed, the whole thing will start to run… and it will not stop. Rapidly your program behaves like an ‘atomic clock’. Writing Ada code feels like playing with this super reliable hifi amplifier made in the 70s that still delivers the best, clean and powerful sound there is even after having been abused for years; you are dragged in ‘deep respect land’. Once you experience what I call the Ada ‘solidity’, other technologies starts to feel like tacky toys ... really.
The guys who laid out the Ada foundations were brutally smart. Take C++ global namespaces, named namespaces and anonymous namespaces. Combination of those three often leads to pure abomination in terms of maintenance, integration, compiling, porting, linking, errors reporting etc. These 'flexible' C++ features, when deployed in huge and complex software projects become liabilities; they are in fact ‘unstable’ features. In stark contrast, Ada packages are extremely straight shooters. They 'behave' correctly all the time, in all context; the thing is simple and just well designed. If the Ada packages piss you off at some point, it's always for a good reason; you are the ‘hackery pervert”, not the language. In my experience even if it was sometimes hard to admit, in the end, Ada was always right about my design and bending to its ruling undeniably made my architecture better.
If it was the end of the world and I had to choose a single compiler to get on a machine it would be an Ada one, not because I am blindly sold to the language but because it has shown to me, practically, to be superior in every possible way.
Not a single feature per se but I would say, its super low level to super high level capabilities wrapped in sound mechanism with virtually no redundancy. Look at any Rosetta Code problem; the Ada solution always shines for its clarity and implicit performance; C/C++ ballpark. It has the approachability of modern scripting languages, flexibility/reach of true bare metal and the maturity of a language ecosystem that kept evolving over many decades; from a time where resources were limited to a time where computing is ubiquitous. Ada is geared towards making applications in a productive, reliable way without wasting CPU cycle. What more would I want?
None really. I get there is some annoyances here and there (see Luke A. Guest interview for a comprehensive overview), but I do not consider those fundamental flaws. I am used to deal with way worse. I too, would appreciate a fork, a reboot, without compromises but the politics and the money does not seem to be there. On the other hand Ada is more than good enough, so.
Very bright actually. I think more and more talented people are getting over syntactic sugar, hype, typeless uselessness, bloated abstraction, functional orthodoxy and realize how it adds nothing to ‘real world software’ quality. From that point on Ada will pick up because it has more to offer than anyone can need.
Personally, under comparable effort and tech availability, I do not see why any of my company's software would not deserve to be built upon what makes airplanes stay in the air and satellites tick. I actually think the best competitive advantage one could get, as we speak, is to build everything in extremely robust and performant, yet productive, fashion; this is exactly what Ada offers you. If I was a big boss I would force everything in Ada because over time building upon previous solid work can only get you lasting results. Do not forget that compared to C++11, Ada 2012 is really easy to learn, use and deploy; I know what I am talking about, I experience both almost every day.
The state of affairs these days in big C++ shops is a bit sad in my opinion; reusability is near zero (with reasons), redundancy is all over, maintenance is a nightmare, most solutions are more complex than they would need to be, velocity is always halted by extremely cryptic ‘legacy bugs' of all sorts, major refactoring is practically impossible and any prior foundation is shaky or has blurred boundaries more often than not ... because of the combination of the previous facts. It's the ‘hacking culture meets corporations short term objectives and complete disinterest in craft’ crumbling under its own weight in a sense.
parallel for ... from what I understand it will be there.